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Előszó 


Napjaink gyakorlatilag egyeduralkodó programozási paradigmája az objek- 
tumorientált programozás (OOP). A szoftverrendszerekkel szemben támasz- 
tott követelmények — főként az átláthatóság és a karbantarthatóság — eddigi 
tudásunk alapján leginkább ebben a megközelítésben kezelhető. A C-t prog- 
ramozási nyelv nem a legfiatalabb objektumorientált nyelv, az utána követ- 
kező programozási nyelvek, így a Java és a Ci jelentős mértékben egyszerűsí- 
tik a nyelvi koncepciókat. Ezek alapján az is elmondható, hogy a Ctt nem a 
legegyszerűbb 00 nyelvek közé tartozik. Mindezek ellenére a nyelv nemcsak 
a különös szakmai kihívásokat öncélúan gyűjtő programozók , sportszerű ne- 
hezítésként" használt eszköze, hanem az operációs rendszerek, a POSIX plat- 
formok és számos beágyazott rendszer alapja. Ennek oka a C nyelvtől örökölt 
gépközeli konstrukciók megtartása, ebből adódó sebessége, és a C nyelv ,ve- 
szélyes" megoldásainak biztonságossá tétele. A sebességnek természetesen 
ára van: a Ctt nyelvben a figyelmetlen programozó nehezen felfedezhető hi- 
bákat ejthet, és a nyelv hiányos ismerete hamar megbosszulja magát valami- 
lyen nem várt vagy rejtélyes működés által. 

E könyv azzal kíván segítséget nyújtani, hogy rámutat azokra a részekre, 
ahol a programozónak komolyan oda kell figyelnie a kódolásra, illetve arra, 
miként csökkentse különböző megoldásokkal a hibalehetőségeket. 

Ezenkívül fontos szempontnak tartjuk, hogy a nyelv logikáját megismerve 
rögtön tudjuk a szokatlan viselkedés okát, valamint képesek legyünk megelőzni. 

A harmadik célkitűzésünk az volt, hogy az objektumorientált szemlélet 
áthassa a C-t nyelvi konstrukcióinak ismertetését, általános , világnézetbe" 
helyezve őket ne csak azt írjuk le, hogyan működnek, hanem az adott konst- 
rukció használatát, az átláthatóbb szoftver készítését elősegítő funkcióját is 
megmutassuk. Ez a célkitűzés indokolja, hogy könyvünk címében nem a 
programozás, hanem a szoftverfejlesztés szerepel. Ahol tehettük, az újonnan 
bemutatott ismereteket példákkal illusztráltuk. 

A könyv öt fő egységre tagolódik. A bevezetést a C nyelv ismeretét feltétele- 
ző Cs tárgyalás hagyományos fejezete követi: témája, hogy miként teszi ké- 
nyelmesebbé a C--t a C nyelvet. Régebben az erről szóló fejezetek jóval terje- 
delmesebbek voltak, de a C nyelv fejlődése következtében ma már kevesebb 
különbséget tapasztalhatunk. 

A kilenc fejezetet felölelő második egység a Ctt objektumorientáltságot 
támogató lehetőségeit mutatja be. Itt kerül sorra az egységbe zárás, az adat- 
rejtés és az öröklés alapelveinek megvalósítása, valamint néhány további le- 
hetőség: az operátorok túlterhelése, a névterek, a kivételkezelés, a sablonok 
bemutatása. 

















Előszó 
ből álló harmadik egységet a szabványos Ct-- könyv. 
el a tárolók és az algoritmusok bemuta. 
tására példákon keresztül. Ezt a fejezetet nem Ör izlllo UNE jatek célunk 
az volt, hogy a könyvtár dokumentációjával együtt — tg y sokszor a fordító 
dokumentációjának része — az Olvasó képes legyen hatékonyan felhasználni a 
sablonkönyvtár nyújtotta lehetőségeket. Ebben a részben kapott helyet a ma. 
ű fej és tárgyalása is. 

GAS SARÁ pen mefoessán UML osztálydiagramok €pb implementációjával 
foglalkozunk, amelyet egy nagyobb esettanulmány zár. Az esettanulmány 
nemcsak az UML nyelvű modellezést illusztrálja, hanem az egész könyv főbb 
fejezeteinek mondanivalóját is. § 4 

Az ötödik egységet a függelékben elhelyezett útmutatások alkotják. Első- 
ként bemutatjuk C--- operátorainak precedenciatáblázatát. Ezután azok szá. 
mára, akik ipari projektet indítanának, bemutatjuk néhány gyakran használt 
eszköz (Microsoft Visual C-t és GNU Compiler Collection) sajátosságait. Mivel 
ezek a különbségek zavarnák az egységes és platformfüggetlen tárgyalást, a 
függelékben kaptak helyet. Végül röviden összefoglaljuk a C programozás meg- 
szokott konstrukcióinak Ct--beli megfelelőit. 

A könyv alapját a Budapesti Műszaki és Gazdaságtudományi Egyetem 
Villamosmérnöki és Informatikai Karán választható Szoftverfejlesztés Ctt 
nyelven tantárgy, a műszaki informatika szak alapképzésében oktatott Prog- 
ramozás alapjai II., valamint a villamosmérnöki szak alapképzésében megje- 
lenő Programozás alapjai 2. tantárgy előadásai és kapcsolódó laborfoglalkozá- 
sai képezik. Így a könyv első fejezetei feltételezik, hogy az Olvasó tisztában 
van a C nyelv alapjaival, az alapvető adatstruktúrákkal (dinamikus tömbök, 
láncolt listák, bináris fák) és algoritmusokkal (keresés, rendezés), emellett 
rendelkezik elemi programozástechnikai ismeretekkel, amelyek például az [1] 
irodalomhivatkozásnak megfelelő könyvek áttanulmányozásával szerezhetők 
meg. Ahol csak tehettük, az egyes funkciókat egyszerű példákkal illusztráltuk. 

. Reményeink szerint azok, akik végigolvassák a könyvet, felfedezik a Ctt 
eleinte bonyolultnak tűnő nyelvi elemei mögötti rendszert, a nyelv logikáját, 
elsajátítják az objektumorientált szemlélet alapjait, valamint képesek lesznek 
hatékonyan kihasználni a szabványos Ct-t- könyvtár lehetőségeit. 


A könyvet tankönyvként használók számá ö ző fej feldolgo- 
zását javasoljuk: számára a következő fejezetek feldolg: 


Az ismét egy fejezeti ő ; 
tárnak szenteltük, különös tekintett. 


5 Ct- alapkurzus nem szoftver irá ago 7- 
szakirányos képzésben: 2-5, 6.1-6.5, 7 
8, 9.1-9.4, 10-11, 12.11, 12.5.3 B gzeztl gtbáó 


Sz alapkurzus szoftver szakirányos képzésben: 2—11, 12.1, 12.5, 13, 
" Haladó C$- kurzus: 12-14 


Beágyazott A 
94. 10-1i — szerek programozása kurzus: 2-5, 6.1-6.5, 7-8, 9.1- 





SZÁE ÉR És B 
Igyekeztünk elérni, hogy az egyes fejezetek a lehetőségekhez mérten és a té- 
ma jellegétől függően önálló egészet alkossanak, esetleges rövidebb ismétlé- 
sek árán is. Mivel jelen munkát nem kézikönyvnek szántuk, hanem elejétől a 
végéig elolvasható tankönyvnek, a felépítés kialakítása során nagy hangsúly- 
lyal vettük figyelembe a didaktikai szempontokat. A C--k nyelvben minden 
mindennel összefügg, így már az első fejezetekben előfordul, hogy egy adott 
jelenség magyarázatát csak egy későbbi fejezet megismerése után lehet meg- 
érteni. A könyv összeállítása során, ahol csak lehet, elkerültük ezeket a hely- 
zeteket. Ahol nem sikerült, ott lábjegyzetbeli vagy egyéb utalással mutatunk 
rá az összefüggésekre. Másrészről vannak olyan osztálykönyvtárbeli elemek 
— jellemzően a kiírást, illetve beolvasást megvalósító objektumok —, melyek 
használata egyszerű, ahhoz viszont, hogy teljes mélységükben tárgyalhassuk 
őket, gyakorlatilag az egész C-t nyelvre szükségünk van. Ezek tárgyalását 
két részre osztottuk: egy bevezető fejezet ismerteti a használatukat, a későbbi 
fejezetek pedig részletesen bemutatják a működésüket. 

Az itt leírt ismeretek tananyagként való számonkérése a téma jellege mi- 
att különösen nehézkes. Ezt megkönnyítendő a számon kérhető fogalmakra 
és a fontosabb mondanivalóra vastag betűkkel és útmutatókkal hívtuk fel a 
figyelmet, valamint a könyv végén , kislexikon" jelleggel kigyűjtöttük a fonto- 
sabb fogalmakat és magyarázatukat. A haladóbb fejezetek címeit dőlt betűtí- 
pus és a végén " jelzi. A folyó szövegben gyakran hivatkozunk a programkód- 
ban szereplő változókra, konstansokra, makrókra stb. Ezeket az elkülöníthe- 
tőség végett dőlt betűkkel szedtük. A programrészleteket szürke háttér jelzi. 
A programrészletekben található megjegyzések magyar nyelvűek, az általuk 
kiírt szöveg nyelve angol, kivéve a magyar nyelvű fejlesztést és a szövegfel- 
dolgozást ismertető fejezetekben. 

Az egyes új fogalmak mellette további tájékozódás megkönnyítésére záró- 
jelben közöljük az angol megfelelőiket. Az angol neveknél vastag betűvel je- 
löltük meg a fogalorahoz kapcsolódó gyakrabban használt betűszéót, illetve rö- 
vidítést. 

Jelen munkában a szerzők többéves ipari és oktatási tapasztalatai is meg- 
jelennek, amelyek számos projekt, internetes oldal, kurzusanyag eredményei 
- ezek forrásai ma már felidézhetetlenek. A köszönetnyilvánításban igyekez- 
tünk ezt némileg pótolni. Vannak olyan források (jellemzően a fordítók do- 
kumentációi), amelyeket lépten-nyomon használtunk, ezekre nem hivatko- 
zunk minden egyes alkalommal. 

Elsőként szeretnénk megköszönni Adamis Gusztáv különösen gondos lek- 
tori munkáját és értékes tanácsait. Köszönetünket szeretnénk kifejezni Péteri 
Szilárdnak és Kovács Tibornak a borító és a CD-melléklet külső megjelenésé- 
nek elkészítéséért, valamint az Automatizálási és Alkalmazott Informatikai 
Tanszék Alkalmazott Informatika Csoportjának, hallgatóinknak és a kiadó 
munkatársainak. Továbbá köszönettel tartozunk Iváncsy Renátának, Kovács 
Ferencnek, Lengyel Lászlónak, Vajk Istvánnak és Vajk Tamásnak a kézirat 
átolvasásáért és az értékes megjegyzésekért. 














Előszó 





Végül pedig bízunk abban, hogy ez a könyv sokak számára lesz megbízha- 
tó segítség tanulmányaik és munkájuk során, és reményeink szerint mindez 
számos áttekinthető, igényesen megírt, jól használható és hatékony C-- 
nyelvű szoftver elkészítésében jelenik meg. 


Budapest, 2007. augusztus 


A szerzők 





ELSŐ FEJEZET 


Bevezetés 


A Ct- általános célú programozási nyelv, amely lehetővé teszi az objektum- 
orientált és generikus programozást, ugyanakkor alacsony szintű nyelvi 
konstrukciókat is támogat. A Ct--t Bjarne Stroustrup fejlesztette ki az ATgT 
Bell Laboratories kutatóintézetben. Az első verzió 1983-ban jelent meg, ennek 
a neve C with Classes (,C osztályokkal") volt. A C-t 1998-ban szabványosí- 
tották [4], aminek során két fontos dolgot egységesítettek: a nyelvet és a hoz- 
zá tartozó Szabványos C-t- könyvtárat. A szabvány 2003-as változata tartal- 
mazza az 1998-as verzió hibajavításait. 

A Cs a C nyelvre épül: az első C-t fordítók C kódot generáltak. A C-t 
sokan a Ct- nyelv egy részhalmazának tekintik, hiszen a C-t a C szintaxisra 
épít, azt terjeszti ki. A legtöbb C program valóban Ct-- program is, de van 
köztük néhány különbség. Ezekre könyvünkben felhívjuk a figyelmet. 

A manapság használt fordítók tartalmaznak C és C-t fordítót is. Sokszor 
ugyanaz a program működik C, illetve C-t fordítóként, a forrásfájl kiterjesz- 
tése, illetve a megadott parancssori argumentumok alapján döntik el, hogyan 
fordítsák a programunkat. Két fordító használatának alapjait a ,,B" függelék- 
ben részletezzük. 

A CH további fejlődését a következő szabvány jelenti, amely jelenleg 
C440x fantázianévre hallgat. Az új szabvány valószínűleg támogatja az auto- 
matikus memóriakezelést (garbage collection), és a párhuzamos programo- 
zást. A szabvány feltehetően 2009—2010 körül jelenik meg. 

















MÁSODIK FEJEZET 


A Ct4 nem objektumorientált 
újdonságai 


Említettük, hogy a Ct- nyelv elődjének, a C nyelvnek a továbbfejlesztése. Eb- 
ben a fejezetben bemutatjuk az újításait, amelyek közül jó néhány a C nyelv 
, veszélyesnek" bizonyuló elemeit cseréli le biztonságosabb megoldásokra, né- 
hány pedig egyszerűen csak kényelmi szolgáltatás (alapértelmezett függvényar- 
gumentumok), vagy átláthatóbb programkódot tesz lehetővé (függvénynevek 
túlterhelése). Ezek eltérnek a C nyelv szintaktikájától, így az ebben a fejezetben 
bemutatott lehetőségeket használó programok csak C-t fordítóval fordulnak. 


2.1. A C és a Cst nyelv 


2.1.1. Függvényparaméterek és visszatérési érték 


Ha egy függvényt a C nyelvben üres paraméterlistával definiálunk, akkor az 
tetszőleges számú paraméterrel hívható.! A C-t nyelvben azonban az üres 
paraméterlista egy void paraméter megadásával ekvivalens. Ennek jelentése 
pedig az, hogy a függvénynek nincs paramétere. Tekintsük az alábbi C függ- 
vénydefiníciót: 





Természetesen C--t nyelven is lehetőség van tetszőleges számú paraméterrel 
hívható függvények definiálására a következő módon: 


1 A paraméterek a függvényben az cstdarg.h? fejlécfájlban definiált makrókkal érhetők el. 














2. fejezet: A Crr nem objektumorientált újdonságai 


A két nyelv a függvény visszatérési típusának meg nem adása esetén is elté- 
rően viselkedik. Az 





függvény esetében a visszatérési érték típusa a C nyelvben int, míg a kódot 
Csi fordítóval fordítva fordítási hibát kapunk, ugyanis a Ct-t nem támogat 
alapértelmezett visszatérési típust. 


2.1.2. A main függvény 


A szabványos C--- nyelvben a main függvénynek két formája létezik: 





valamint 


NEKEG SB paraméterben a parancssor-argaumentumok számát, az argu pa- 
ram en pedig a parancssor-argumentumokat kapjuk meg. Érdekes mó- 


don a main függvényben nem kötelező a return használata. Amennyiben nem 


ha: a. z Ki kt : ítá 
faedit seb a. (ORSÓ automatikusan sikeres lefutást jelző return 0; utasítást 


2.1.3. A bool típus 

A C44 nyelvben bevezették a bool tí; r Égő 
tálni pust, ami logikai igaz/hamis értéket ké- 

TRLÁNEGÁSOT - A bool típusú változók true vagy false értéket vehetnek fel, 


CESSNA EE EKB JT zet tg éTe 


Él 





2.1. AC ésa Css nyelv 
A C nyelvben a logikai értékek int vagy enum típusú kifejezéssel z 
hatók. A bool típus bevezetésének előnye, Gy elkalneeáá öreisttéet kój 
dot eredményez, valamint lehetőség van a függvénynevek és operátorok bool 
és int típusokra vonatkozó, különálló túlterhelésére.2 Szerencsére létezik au- 
tomatikus konverzió a bool és int típusok között: a 0 int érték false-nak, min- 
den más érték true-nak felel meg. A bool, a false és a true a C4-4 nyelv kulcs- 
szavai közé tartoznak. 


2.1.4. C stílusú több-bájtos sztringek 


Már a C nyelvben is létezik a több bájtos, például Unicode karakterek repre- 
zentálására alkalmas wchar t típus. Ám használatához tinclude-olni kell a 
Sstddef.h:, cstdlib.h2 vagy Swchar.h: fejlécfájlok valamelyikét, melyekben a 
wchar.t a következőképpen definiált: 





A Ct4 nyelvben a wchar t beépített típus lett, így használatához a fenti tí- 
pusdefinícióra nincs szükség. Több bájtos karakter- és sztringliterálok definiá- 
lására a C-ben megszokott módon van lehetőség: 





Ezt a témakört részletesen a 12.6. Magyar nyelvű fejlesztés részben tárgyaljuk. 


2.1.5. Változódeklaráció mint utasítás 


A Ct-4-ban minden olyan helyen állhat változódeklaráció, ahol utasítás áll- 
hat. Erre mutat példát az alábbi kódrészlet: 








2? A függvénynevek túlterheléséről lásd a következő 2.2. részt. 














ri 
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), fejezet: A Cs nem objektumorientá "újdonságai 


"látható, hi n változót ott hozzuk létre, ahol valóban szükségünk 
S úg vert feléjttüle eljhalláta inicializálni. Ezt általában is érdemes 
követni: egy változót közvetlenül az előtt deklaráljunk, ahol fel szeretnénk 
használni. Ennek eredményeként áttekinthetőbb kódot kapunk, és kisebb va- 
lószínűséggel felejtjük el vagy rontjuk el a változó inicializálását. és 

Ezek után foglalkoznunk kell az így deklarált változók hatókörével. Ter. 
mészetesen minden változó onnan kezdve használható, ahol deklaráltuk. Az 
érvényesség végét annak a blokknak a vége jelenti, ahol a változót deklarál- 
tuk. Mindez még nem ad választ az if, illetve a for utasítások fejlécében dek- 
larált változók érvényességének határaira. Ezek a változók csak az utasítások 
törzsében érvényesek. Vagyis fenti példánkban nem használhatjuk az i válto- 


zót a — jelenleg egy utasításból álló — ciklustörzsön kívül. 





e,  — — — —,———,————,———— 
Útmutató: Cs: nyelven mindig akkor deklaráljunk változót, amikor rögtön fel is használjuk. 
 Eemutató: ur nyelven ms 


2.2. Függvénynevek túlterhelése 


Egy függvényt a C nyelvben a neve azonosít egyértelműen, így egy adott ha- 
tókörben két azonos nevű függvény nem deklarálható. A C--- nyelvben a 
függvényeket a nevük és az argumentumlistájuk együttesen azonosítja. Így 
lehetőség van azonos nevű függvények létrehozására, amennyiben az argu- 
mentumlistájuk alapján egyértelműen megkülönböztethetők. Fontos, hogy a 
függvény visszatérési értékének típusa nem jelent megkülönböztetést! Néz- 
zük meg az alábbi példát: 








aa túlterhetése 





A megoldás előnye, hogy az egyes függvényverziókhoz nem kell! különböző — sok 
esetben erőltetett — nevet kitalálni. 

Vizsgáljuk meg, hogyan valósítja meg belül a fordító a függvénynevek túl- 
terhelését! Az alapelv az, hogy a függvényneveket kiegészíti az argumentum 
típusaiból képzett elő- vagy utótaggal. Így a különböző paraméterlistájú, de 
ugyanolyan nevű függvények a linker szintjén különböző névvel jelennek 
meg. Ezt a technikát névelferdítésnek (name mangling) nevezzük. Míg a C 
nyelv úgy hivatkozik egy függvényre a linker szintjén, hogy egy aláhúzást 
tesz a függvénynevek elé, addig a Ct- az egyes fordítókra bízza a névferdítés 
implementálását.? 

Ez a különbség problémássá teszi a C és a Ct-t kód együttműködését. Ho- 
gyan férhetünk hozzá egy már meglévő, C fordítóval lefordított függvényhez 
C---ból? Erre szolgál az extern "C" deklaráció, ha ezt a függvény deklarációja 
elé írjuk, akkor a fordító a C nyelvben megszokott módon fordítja és linkeli a 
függvényt. 





5: Például a Microsoft Visual C-t fordító a double eppfunc(int a, double b) függvényre a 
feppfuncci(odYANHNGZ elferdített névvel hivatkozik (a €a előtti HN-ből a H jelenti az int, 
az N a double paramétert. A gtt esetén ez a függvény a . Z7eppfuncid nevet kapja. 

A lefordított tárgykódú állományokból Windows alatt a dumpbin /SYMBOLS segédprog- 
rammal (a dumpbin a Visual C4- része), Unix/Linux alatt az nm vagy az objdump -t 5e- 
gédprogrammal írathatjuk ki a linker által használt függvényneveket. 














2. fejezet: A Crr nem objektumorientált újdonságai 
Példánkban egy nem túl bonyolult C függvényt szeretnénk Ct--ból fel. 


használni, amely összead két egész számot. Ezt a függvényt lefordították, és 
számunkra csak linkelhető formátumban áll rendelkezésre. 





Ezt a függvényt az alábbi módon hívhatjuk meg C-t--ból: 





// eppfile.cpp Crr fordítóval fordítjuk 
tincludecstdio.ho TE azaz etez tet 


. szerinti névelferdítéssel 
-osszeadCint a, int b); 










/7.€ függvény 
MEZ sg im 


int mainO 
TE AKT 





CAF", csosszead(1, 29); 3 





[5 Az eredmény: 3 §/ 


A c névelferdítéssel használt függvényeket természetesen nem terhelhetjük 
túl, hiszen a fordítónak éppen a túlterhelést lehetővé tévő mechanizmusait 
tiltottuk le. 

C fordítóval fordított programból nem tudunk C-t névelferdítéssel fordí- 
tott függvényeket hívni. Vagyis, ha egy C--t függvényt szeretnénk C-ből hív- 
ni, akkor a Ctt kódban kell egy extern "C" függvényt definiálni, amely meg- 
hívja a kívánt Ct-t függvényt. 


2.3. Alapértelmezett függvényargumentumok 


A Ci nyelvben lehetőség van arra, hogy a függvények argumentumainak 
alapértelmezett értéket adjunk meg. Amennyiben ezen argumentumoknak a 
függvény hívásakor nem adunk meg értéket, a függvény az adott argumen- 
tum alapértelmezett értékével kerül meghívásra. Az alapértelmezett argu- 
mentumok használatát az alábbi kódrészlet szemlélteti: 








Tegyük fel, hogy a CreateWindow olyan függvény, amellyel egy új ablakot tu- 
dunk az általunk használt környezetben létrehozni. A függvény három paramé- 
terrel rendelkezik: a caption paraméterben az ablak fejlécének szövegét, az x és 
y paraméterekben pedig az ablak képernyőkoordinátáit lehet megadni. Az x és 
y paramétereknek a 100 alapértelmezett értéket adtuk, míg a caption paramé- 
ter nem kapott alapértelmezett értéket. A main függvényben a függvény hívá- 
sának különböző módjaira látunk példát. Az első sorban minden argumentum- 
nak adtunk értéket, a függvény ezeket kapja meg paraméterül. A második sor- 
ban x és y az alapértelmezett 100, 100 értéket veszi fel. Az utolsó sorban x az 
explicit megadott 200, y az alapértelmezett 100 értéket kapja. 

Az alapértelmezett argumentumok alkalmazásának szabályai a következők: 


e — A függvénydefinícióban alapértelmezett értékek megadására az argu- 
mentumlistában hátulról előre folytatólagosan van lehetőség. Ennek 
következtében az alábbi függvénydefiníciók hibásak: 
void CreateWindow(char"caption, int x - 100, int y) (...), 
void CreateWindow(chartcaption - "Hello world!" int x, int y - 0) (... 


e A függvényhívás során az alapértelmezett argumentumok az argu- 
mentumlistában hátulról előre folytatólagosan hagyhatók el. Így az 
alábbi függvényhívás hibás: 

CreateWindow( "Hello world!" , 200 ); 


s — Az alapértelmezett argumentumok nem adhatók meg egyidejűleg a 
függvénydefiníció és a függvénydeklaráció helyén, így mindig csak az 
egyiknél adjuk meg. Az alábbi kódrészlet ezért hibás: 

77 Deklaráció: 

void CreateWindowK( char" caption, int x - 100, int y — 100 ); 

17 Definíció: 

void CreateWindouK( char" caption, int x - 100, int y — 100)£...) 


Az alapértelmezett argumentumokat a legtöbb esetben a függvénydeklaráció- 
nál célszerű megadni, mert a felhasználás során általában ez áll a függvény 
hívójának rendelkezésére adott fejlécfájlban. ép 
Az alapértelmezett argumentumok és a függvénynév-túlterhelés egyidejű 
alkalmazása kétértelműségi problémát, és így fordítási hibát okozhat: 














2. fejezet: A Cst nem objektumorientált újdonságai 





2.4. Paraméterátadás referenciatípussal 


Vizsgáljuk meg az alábbi C programot! 





Mivel C-ben kizárólag érték szerinti paraméterátadás történik, az / függvény 
hívásakor az a változó értéke lemásolódik a veremre, és erre a másolatra hi- 
vatkozunk az i szimbólummal az f függvényen belül. Így az i változtatása is 
csak ezt a másolatot érinti, az a változó értékét a függvényhívás egyáltalán 
nem befolyásolja: a program kimenete 0 és egy soremelés lesz. Habár ez szin- 
taktikailag helyes, működő program, valószínűleg nem ez volt a programozó 
szándéka. Ha szeretnénk, hogy a függvény megváltoztassa a paraméter érté- 
két, egyszerű mechanikus átalakítást kell végeznünk a fenti programon, amit 
az alábbi kódrészlet illusztrál: 
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——— Tá Paraméterátadás referencatioussat 


A mechanikus átalakítások a következők: a függvény paraméterlistájában 
pointert veszünk át változó helyett (a változónév elé írunk egy csillagot, és 
— természetesen nem kötelezően — a névben egy jelölést, hogy pointerrel van 
dolgunk), illetve mindenhova, ahol eddig a változónév szerepelt, a (pointer) 
kifejezést írjuk. Természetesen a zárójel néhol elhagyható lenne az operáto- 
rok precedenciáját figyelembe véve, de egyfelől így biztos mindig ugyanazt a 
működést kapjuk, másfelől ekkor átalakításunk már nem lenne mechanikus: 
gondolkoznunk kellene. A harmadik átalakítás, hogy az átadott változó he- 
lyett a változó címét kell átadni, vagyis az átadandó változó elé egy £ jelet 
írunk. A magyarázathoz tekintsük meg az alábbi ábrát! 


int pi - §a inta 


ES ezi 


1. ábra. A változó címének átadása 


Az átadott érték (az a változó címe) ez esetben egy pointer, amelyről szintén 
másolat készül (a másolatra a függvényben a Pi szimbólummal hivatkozunk), 
de értelemszerűen ugyanarra a változóra mutat, mint az eredeti. Így a " operá- 
tor segítségével hozzá tudunk férni az a változóhoz, és meg is tudjuk változtatni 
az értékét. Ezt illusztrálja memóriaképpel a fenti ábra: bal oldalon a téglalap 
által reprezentált memóriarekeszben az a változó címével inicializált pointer 
helyezkedik el, amely a jobb oldali téglalap által megjelenített a változó memó- 
riarekeszére mutat (ezt jelöli a nyíl). Ezáltal a program kimenete 2 és egy sor- 
emelés lesz. Mivel itt a változó címét adjuk át, ezt a megoldást cím szerinti pa- 
raméterátadásnak nevezzük, szemben a korábban bemutatott érték szerinti pa- 
raméterátadással. Az előbbi esetben másolat készül a változóról, és azon végez- 
hetünk műveleteket, amelyeknek semmilyen hatása sem lesz az eredeti válto- 
zóra, míg a cím szerinti esetben megváltoztathatjuk a változó értékét. C nyel- 
ven , kézzel", vagyis pointerek segítségével kell megoldanunk a függvénypara- 
méterek cím szerinti átadását. Ez azt jelenti, hogy a C nyelvben a pointerek 
egyik felhasználási területe éppen a cím szerinti paraméterátadás.! Ugyanak- 





1 AC pointerek másik felhasználási területe a dinamikus memóriakezelés, amikor futási 
időben derül ki a szükséges memória mérete, ezért a malloc függvény segítségével lefog- 
laljuk a szükséges memóriát, majd használat után a free függvény segítségével felszaba- 
dítjuk, A két terület megkülönböztetése nagyon fontos, és kezdő programozók esetén 
gyakori hibaforrás: azért mert egy függvény pointert vár, nem feltétlenül kell pointert 
deklarálnunk és mallockal helyet foglalni, lehet, hogy a függvény csak meg akarja változ- 
tatni a paraméter értékét, vagyis valójában egy változó címét várja. 


n 














2. fejezet: A Crr nem objektumorientált újdonságai 


kor felmerül a kérdés: ha ez teljesen mechanikus, gondolkodást nem igénylő 
átalakítás, miért nem tudja a fordító levenni a vállunkról ezt a terhet, és elvé. 
gezni az átalakításokat? Ezt a problémát oldja meg a Ct- a referenciatípus be. 
vezetésével, ami feleslegessé teszi a pointereknek a cím szerinti paraméterát. 
adásban betöltött szerepét.5 Alakítsuk át példánkat a C-t cím szerinti paramé. 
terátadás szellemében! 





Jól látható, hogy az érték szerinti paraméterátadáshoz képest egyetlen ka- 
rakterrel kellett módosítani a programot, nevezetesen egy £ jelet kellett írni 
a paraméter deklarációjában a változónév elé. Az i szimbólum típusának neve 
referencia. A fenti C4-- program tulajdonképpen ugyanazt a működést eredmé- 
nyezi, mint a pointereket használó C program, viszont nem kell a változó címét 
képezni, és az i szimbólumot ugyanolyan szintaxissal használhatjuk, mint egy 
int típusú változót. Mivel az i referencia megváltoztatása egyenértékű az a vál- 
tozó megváltoztatásával, így a program kimenete 2 és egy soremelés lesz. Ve- 
gyük szemügyre közelebbről a referenciatípussal kapcsolatos szabályokat! 

4 Amint az alábbi példa is mutatja, egy adott típusú referenciát a referen- 
cia neve elé írt €t jellel deklarálunk, Az 8 jelnek van más funkciója is, ame- 
lyet a C nyelvből hozott magával: egyargumentumú operátor, amely a mögöt- 
te álló változó címét adja vissza. Funkciójánál fogva ez az operátor nem sze- 
repelhet deklarációban, így nem jelent különösebb problémát, ha a C-t fel- 


használja ezt a jelet a referencia deklarálá ; bbi 
ÓdOn ASE JÁThSÉ ÉKE arálásához. Referenciaváltozót az alál 


SZESZ SE SE 

" ást fojetk Táti bevezetésének szükségességét a 6. fejezetben, az operátorok túlterhelé: 

ramóterátadásra vege, ftban a pointereket nem használjuk cím szerinti pa: 

területét vezeti be, a Pointereknek egy új, a C-ben ismeretlen felhasználási 
"mely a 7. fejezetben, a polimorfizmus tárgyalásánál j SEMBÉSÉ 
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A fenti programrészletben p! és p2 értéke megegyezik, ugyanis mindkettő az 
x változó címét tartalmazza: a referencia címe a hivatkozott változó címe. Az 
alábbi kódrészlet alapján összehasonlíthatjuk a pointer és a referenciatípus 
deklarációját: 


Az első sorban deklarálunk egy int típusú változót, a második sorban egy int 
típusú mutatót, amelynek az x változó címét adjuk kezdeti értékül. Ezek után 
egy int típusú referenciát hozunk létre, amely az x változóra fog hivatkozni. 

Mivel a referencián keresztül meg akarunk változtatni egy változó érté- 
ket, csak megváltoztatható kifejezést adhatunk a referencia kezdeti értéké- 
nek (például nem lehet konstans). Ez alól kivételt képez a konstans referen- 
cia, amelyet később részletezünk. 

Ritkán szoktunk referenciával hivatkozni egy változóra, hiszen áttekint- 
hetetlenné teszi a programot, ha egy változóra több szimbólummal is hivatko- 
zunk. A referenciatípus igazi felhasználási területe a cím szerinti paraméter- 
átadás. Mivel a C---ban a cím szerinti paraméterátadást referenciákkal va- 
lósítjuk meg, és a C4-4-t sok szempontból alapul vevő programozási nyelvek 
(Java, C$) megtartották ezt az elnevezést, ezt a mechanizmust gyakran refe- 
rencia szerinti paraméterátadásnak is nevezzük. A függvényparamétereknél a 
kötelező kezdeti értékadás automatikusan teljesül, és a referencia megváltoz- 
tatása a paraméterként átadott változó megváltozását eredményezi. 

Problémák forrása lehet, ha egy függvény referenciával tér vissza. Ilyen- 
kor a fordító egy ideiglenes referenciaváltozót hoz létre, amelyet a visszaté- 
résként megadott változóval inicializál. Amikor a függvény visszatérési érté- 
kével végzünk műveletet, akkor ezzel a referenciával végzünk műveletet. Em- 
lékezzünk vissza arra, hogy közvetlenül a függvény visszatérése után a függ- 
vényparaméterek és a lokális változók felszabadulnak. Ezért ezekre nem sza- 
bad referenciával (illetve pointerrel) visszatérni, mert érvénytelen memória- 
területen elhelyezkedő, már felszabadított változóra hivatkozunk. Vizsgáljuk 
meg a következő programot! 














2. fejezet: A Ctt nem objektumorientált újdonságai 





A programot lefuttatva semmi különöset nem tapasztalunk, az eredmény 3.14 
és egy soremelés, talán még meg is lepődünk a fordító figyelmeztetésén, hogy 
kiszolgáltattuk a lokális pi változóra hivatkozó referenciát a függvénytörzsön 
kívülre. Használjuk most egy kicsit másképpen az init pi függvényünket! 











A fenti programrészlet az általunk használt fordító alatt 0.000000-t írt ki két: 
szer. Ha belegondolunk a vermen keresztüli paraméterátadás működésébe, ez 
nem meglepő. Amikor ugyanis a veremből kiszedünk egy elemet, csak A Vé 
rem tetejét jelző veremmutatót módosítjuk, a felszabadult területet nem 
Ezért az első programrészlet az érvénytelen területen maradt lokális változ 


Bai hivatkozik, amely a helyes értéket tartalmazza. A második esetben viszon! 
újra felhasználjuk a veri 
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néha váratlan futási idejű hibát eredményez. Ezért az erre figyelmeztető for. 
dító üzenetét érdemes komolyan vennünk.§ 
Végzetül keressük meg a lehetséges hibákat az alábbi programrészletekben! 





A "1-es esetben lokális változóra hivatkozó referenciával térünk vissza, így ez 
futási időben hibát jelenthet (a fordító adta figyelmeztetésen kívül). Ugyanez 
a helyzet a "2-es esetben: a paraméterek ugyanúgy a veremben helyezkednek 
el, és ugyanúgy felszabadulnak a függvényhívás után. A vu referencia a main 
függvényben található g változóra hivatkozik, így egy arra hivatkozó referen- 
ciával tér vissza. Mivel a g lokális változó a main függvényben, az fv függvény 
hívása után is érvényes, akárcsak a visszaadott referencia hivatkozása. Így a 
"3-as kódrészlet helyes. A "4-es kódrészlet megpróbálja a referenciát megvál- 
tozhatatlan értékkel inicializálni, ami fordítási hibát eredményez. Az "5-ös 
kódrészlet változót ad át referenciaparaméterként, vagyis helyes, hasonlóan a 
"6-os kódrészlethez. 


SÉRTÉS te Sze sásá sátán saint észszöékéáb ss 
Útmutató: Egy függvényben sose adjunk vissza pointert vagy referenciát lokális változóra 
vagy érték szerint átadott paraméterre! 





§ Itt jegyezzük meg, hogy a fenti program akkor is hasonlóan viselkedik, ha a kerületet 
számoló függvény konstans referenciát vár (lásd 4.1.3. Konstans függvényparaméterek fe- 
jezet), amely pedig nagyon gyakran szerepel optimalizációs megfontolások miatt. 
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2. fejezet: A Cr nem objektumorientált újdonságai 


Végül megjegyezzük, hogy a csak a függvénynek átadott argumentum könnyú 
megváltoztathatósága a referenciának csak az egyik alkalmazási területe, 
Kihasználva, hogy a referencia szerinti paraméterátadás esetén cím szerint 
adjuk át az argumentumot, nagyméretű argumentumok (például struktúrák) 
esetén teljesítménynövekedést érhetünk el, ha csak az argumentumok címét 
adjuk át, és nem másoljuk le őket, jóllehet nem szeretnénk megváltoztatni az 
átadott argumentum értékét. Erről bővebben a 4.1.3. Konstans függvénypa. 


raméterek részben olvashatunk. 
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HARMADIK FEJEZET 


Objektumok és osztályok 


Ebben a fejezetben bevezetjük az objektumorientált szemlélet alapgondolatait, 
majd megismerkedünk az objektumok és osztályok Ct-t implementációjával. 


3.1. Az objektumorientáltság alapelvei 


A számítástechnika fejlődése során a bonyolultabb feladatok megoldása egyre 
inkább a szoftverre hárul. A hardverek néhány, a legtöbb esetben jól szabvá- 
nyosított felületet valósítanak meg egy adott architektúrával (például a Neu- 
mann-architektúra), amelyeknek alacsony szintű utasításkészlete közvetlenül 
nem alkalmas nagyobb feladatok átlátható és könnyen karbantartható meg- 
oldására. Ez az eltolódás érthető, hiszen a hardvert sokkal körülményesebb 
módosítani, mint a szoftvert. Például egy számlázórendszer esetén a folyama- 
tok és számítások bonyolultságának kezelése, amelyeket jellemzően több ország 
számviteli törvényéhez kell igazítani, teljes mértékben a szoftver feladata. 

A tapasztalatok szerint nem elég a szoftver műszaki paramétereire fi- 
gyelnünk. A szoftvert ugyanis emberek, programozók írják, javítják és módo- 
sítják. A feladatot emberek értik meg, és emberek fordítják le a számítógép 
nyelvére. Ahogy a feladat bonyolultsága nő, annál nehezebb a programot át- 
tekinteni, módosítani, illetve továbbfejleszteni. Amint a szoftverrel kapcsola- 
tos követelmények nőttek, az áttekinthetetlenség problémája egyre jelentő- 
sebbé vált, hiszen számos projekt bukását eredményezte a kézben tarthatat- 
lan bonyolultság. Az 1960-as években ez vezetett az objektumorientáltság ki- 
bontakozásáh nely az 1990-es évekre terjedt el igazán. 

Az áttekinthetőség egyik kulcsfontosságú eleme, hogy felhasználják az 
emberek már rendelkezésre álló ismereteit. Ha bankszámláról van szó, min- 
denkinek eszébe jut, hogy a számlának van egyenlege, a számlára lehet pénzt 
elhelyezni, vagy pénzt kivenni róla. Vagyis jó lenne, ha a számla megjelenne 
a programban mint önálló adatstruktúra, és a tulajdonságai (például az 
egyenleg), illetve a rajta végzett műveletek (betesz, kivesz) egy helyen lenné- 
nek, nevezetesen a struktúra részeiként. Ezt az alapelvet nevezik egységbe 
zárásnak (encapsulation), ahol az egységbe záró adatstruktúra neve osztály 
(class). Azért hívják osztálynak, mert az összes számla struktúrájának leírá- 
sát foglalja magában, egyfajta kategóriát definiál. 





























3. fejezet: Objektumok és osztályok 


i (az én számlám egy adott bank- 

Az osztálynak tehát TEL KEBÁTTTOTLTSS 5. rölyek künt öniélló ,egyát 
nál, a szomszédom SEBEKET (object) nevezzük." Például egy számi. 
kezgÉS a ege rVL ÉTÉ öéztálják az ellenfél, az ütő és a labda. Az objek- 
ind edléék példányai: az a labda, amivel éppen játszunk, az ütők, illet. 
"8 ir AzáNTÁKÁK ölsektaln fogalmával elértük, HLHÉS ME Hz sáőn ha 
lajdonságait és a rajtuk végzett műveleteket egységbe z eV PivEK 17 
szünk be a számlára, a beteszPénzt művelet beírja a tranza ció átumát és 
egyéb adatait egy szöveges naplóállományba, majd SELEHBE Gól vele 
leget. Viszont, ha a program többi része hozzáfér az egyenleg f aj isk oz, 
és meg tudja változtatni, akkor a naplózás elmaradhat, ami komoly inkon- 
zisztencia a rendszerben, hiszen a naplónak lépést kell tartania az egyenleg 
változásával. Ha sikerült biztosítanunk az objektumok tulajdonságainak és 
műveleteinek az osztályba való egységbe zárását, akkor eggyel tovább léphe- 
tünk: biztosítanunk kell, hogy az objektum képes legyen , vigyázni magára", 
az objektum ,belsejéhez", vagyis tulajdonságaihoz a program többi része ne 
férhessen hozzá, ne tehesse inkonzisztenssé. Az objektum ezen védekezési 
mechanizmusát hívjuk adatrejtésnek (data hiding). Az adatrejtés mellett 
szól egy másik nagyon fontos érv: ha az objektum belső felépítését, megvalósí- 
tását elrejtjük a külvilág elől, akkor elég az objektum látható műveleteit is- 
merni ahhoz, hogy felhasználhassuk a rendszer megvalósításában, vagyis az 
adatrejtésnek kritikus szerepe van a komplexitás kezelésében is. 

Miután az objektumok a problématérben előforduló dolgokat (úgynevezett 
entitásokat) jelenítik meg, érdemes lehet azok kapcsolatait is szemügyre ven- 
nünk. A lehetséges kapcsolatok közül egy különösen fontos: az , egyfajta" vagy 
más néven az ,az egy" (is-a) kapcsolat. Például egy trafikban az alkalmazott 
egyfajta személy, vagy másként, az alkalmazott az egy személy (an employee 
is a person). Ezt a kapcsolatot nézőponttól függően általánosításnak vagy 
specializációnak is hívják: a személy általánosabb fogalom, mint az alkal- 
KASZUSS illetve az alkalmazott speciálisabb, mint a személy. Ez a kapcsolattí- 
Pus azért kiemelkedően fontos, mert rendelkezik két érdekes tulajdonsággal. 
Ha a személynek van neve, akkor az alkalmazottnak is lesz, hiszen az alkal- 
TELEN £bse egyfajta személy, személy is egyben. Vagyis a speciálisabb osz- 
ÚeÜKöLáke A alánosabb osztály tulajdonságaival és műveleteivel, 
tőségnek 78 dvllesklsaás ; azokat. A másik tulajdonságot behelyettesíthe- 
bármikor kezelhetü 3) nevezzük. Ez azt jelenti, hogy egy alkalmazottat 

i etünk személyként, hiszen az egyfajta" kapcsolat miatt az 
alkalmazott tényleg egy személy, Vagyi negytaj pes § 
bárhol felhasználható, ahol e Végy aoálta egy speciálisabb osztály objektuma 
sabb osztály példányai hel s öcrássagapal osztály objektuma, azaz a speciáli- 
Jettesíthetik az általánosabbakéit. 


" Az osztály telj j Ji 
ly teljes neve objektumosztály, de szinte mindig osztályként emlegetik. 
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3.1. Az öbjektumorientáltság alapelvei 
EG ———— ÖS öbjektumortentáltság tiapetvet 


Ezzel összefoglaltuk az objektumorientált programozás (OOP) három 
alapelvét. Tárgyalásunk során követünk még egyet, amely azonban nem tar- 
tozik az objektumorientáltság alapelvei közé — számos objektumorientált 
(00) nyelvben meg sem jelenik -, a Cs--ban mégis következetesen megtalál- 
ható. Ez a típustámogatás, amely azt jelenti, hogy a felhasználó által defi- 
niált típusok — közöttük az osztályok — úgy viselkedhetnek, mint a beépített 
típusok: például támogathatnak operátorokat és típuskonverziót. 

Az objektumorientáltság egy paradigma, vagyis szemléletmód, A C nyelv- 
ben funkciókra dekomponáltuk a rendszert, a funkciókat függvényekkel való- 
sítottuk meg. Az 00 szemléletmódot követve már az analízis és a tervezés so- 
rán is objektumokban és osztályokban gondolkodunk, ami jobban követi a va- 
lóságot, az ember gondolkodását. Az implementáció eszköze ez esetben pedig 
célszerűen egy 00 nyelv, mint például a C---. Ebben az esetben a rendszer 
funkcióit egymással együttműködő objektumok valósítják meg. Ez az objek- 
tumorientált programozás alapgondolata. 

Végigkísérve a programozási nyelvek fejlődését megállapíthatjuk, hogy a 
fejlődés lépcsőinek, az úgynevezett paradigmaeltolódásnak kettős hatása van: 
a magasabb szintű nyelvek bonyolultabb feladatok áttekinthetőbb megoldá- 
sára képesek, ugyanakkor magasabb szinten az optimalizálás nem lehetséges 
olyan mértékben, mint az alacsonyabb szinten. Egy C program gyorsabban 
fejleszthető, áttekinthetőbb, mint egy assembly program, viszont assembly- 
ben gyorsabb kódot lehet írni. Ugyanakkor mindannyian találkoztunk már 
olyan áttekinthetetlen C programmal, amelyet egyszerűen lehetetlen karban- 
tartani.§ Ekkor nem feltétlenül éri meg igénybe venni a strukturált, magas 
szintű programozási nyelvet, hiszen assemblyben is ugyanolyan áttekinthe- 
tetlen, de gyorsabb kódot lehet készíteni. Látni fogjuk, hogy az objektumorien- 
táltság alapelveinek nyelvi támogatása a C nyelvhez képest teljesítmény- 
csökkenés árán érhető el. Ezért, ha nem törekszünk arra, hogy a problématér 
viselkedését minél pontosabban és egyértelműbben megjelenítsük a prog- 
ramkódban, ezáltal érthetővé és áttekinthetőbbé téve a szoftvert, valamint 
nem törekszünk egységbe zárásra és adatrejtésre, akkor nem érdemes a prog- 
ramot kitenni az objektumorientáltság támogatása miatt bevezetett teljesít- 
ménycsökkenésnek. Célszerűbb inkább strukturált nyelvet választanunk. 

Előfordul, hogy a feladat bonyolultsága és áttekinthetetlensége nem a prob- 
lématér bonyolultságából adódik, például algoritmikus jellegű (egy jelfeldolgozó 
algoritmus egy jelfeldolgozó processzorra). Ilyen és más problémák esetén sok- 
szor előfordul, hogy nem az objektumorientáltság nyújtja a legjobb megoldást. 

Ha viszont a Ct--t választjuk, érdemes szem előtt tartanunk az objektum- 
orientált alapelveket, amelyek segítségével összetettebb problémákat oldha- 
tunk meg, és nagyméretű, jobban karbantartható programokat készíthetünk. 





5 AC nyelv ilyetén való félrehasználását megcélzó verseny (The International Obfuscated c 
Code Contest — kb. nemzetközi összekuszált C kód verseny) weblapja (Attp:/ /www.ioccc.org/) 
minden kétséget kizáróan illusztrálja ennek végrehajthatóságát. 
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eze 


szá sszem — 

Útmutató: Ha a Css nyelvet választjuk egy feladat implementálására, mindig tartsuk szem 
előtt az objektumorientált alapelvek, az egységbe zárás, az adatrejtés és az öröklés helyes al- 
kalmazását! ; 





3.2. Egységbe zárás a Ctt-ban 


Tekintsük meg a következő példát! Programunk koordinátarendszerben végez 
számításokat, a pontokat pozitív x illetve y koordinátájukkal jellemezzük. 
A pontok koordinátái nem lehetnek tetszőlegesen nagyok, az x és y koordináták 
maximumát egy-egy konstanssal adjuk meg. Mivel a két koordináta összetarto- 
zik, C nyelven automatikusan egységbe zárjuk őket egy struktúratípusba. 











essem seazsé ne a OAARÉ alylebárákoltú Csabát 


A példán jól látható, hogy a két függvény ugyanolyan szorosan kapcsolódik a 
két koordinátához, mint a két koordináta egymáshoz. Érdemes lenne tehát a 
pontok SEL Ze El lkáss gegek ásás a SSE tagjaivá tenni. Ez a 
gondolatm ju az egységbe zárás Ct--beli megoldásáh. 

amelyet a következő kódrészlet mutat be: je; 


Ezzel a megoldással a struktúrának nemcsak adattagjai, úgynevezett tagvál- 
tozói (member variable), hanem tagfüggvényei (member function) is lehet- 
nek. A tagváltozót gyakran attribútumnak, a tagfüggvényt metódusnak, il- 
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3. fejezet: Objektumok és osztályok 

p § jük, h 
letve műveletnek is nevezzük. A fenti példán azt is MEL lrénka 1 78 
Cs-4-ban nem szükséges a típust struct Pointként kiírnunk, 


túra nevét használnunk, amely önmagában típusértékű. 


3.2.1. Tagváltozók ú3jA máá 

Mint már említettük, a tagváltozók a struktúra LÁNLERETEKE let: Példánk- 

ban az x és az y a Point struktúra unsigned int típusú tagv: IGA lés 
Amint az alábbi ábra is mutatja, valahányszor egy válto: ozu. 


Point struktúrából, annyiszor foglalódik hely a struktúra tagváltozóinak. 


Point p2; 


Point pt; 





2. ábra. Stuktúrapéldányok 


Ez összhangban van a C nyelv implementációival is, akár csak az, hogy a 2 
és a . operátorokkal hivatkozhatunk a tagváltozókra. Fontos eltérés azonban, 
hogy míg a C nyelvű struktúra memóriaképét az egyes adattagok egymás 
után helyezve alkotják, a Ct-4-ban ez nem mindig teljesül: előfordul, hogy 
számos más adatot! is el kell tárolni a tagváltozók után, ezért a memóriakép 
fizikai felépítését nem használhatjuk ki. Vagyis ha például a C programban 
megszokott módon a sizeof operátorral lekérdezzük a struktúra méretét, majd 
az fwrite függvénnyel egy állományba írjuk, a visszaolvasás után ,eltévedt" 
függvényhívásokat tapasztalhatunk. Ezért ha nemcsak adattagja van a 
struktúrának, a Ct-t-ban tagváltozónként végezzük el az ilyen jellegű felada- 
tokat: tipikusan a másolást és az adatfolyamokba való írást. Megjegyezzük 
továbbá, hogy a Ct- szabvány szerint a sizeof operátor implementációja fordí- 
tónként eltérő lehet. 


3.2.2. Tagfüggvények 


Annak, hogy a függvények is a struktúra részévé váltak, van néhány szintak- 
tikai és megvalósításbeli következménye. Tagfüggvényeket kétféle módon ad- 
hatunk meg: az osztálydefinícióban, ahogy a példa is mutatja, illetve a függ- 
vény törzsét megadhatjuk a struktúradefiníción kívül is. Ez esetben a példa 
— a main függvényt érintetlenül hagyva — a következőképpen módosul: 





8 tevése 7.8. A virtuális függvények megvalósítása fejezetben részletezett virtuális 
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Vagyis a C-ben megszokott prototípushoz hasonlóan a struktúradefiníción be- 
lül a függvény deklarációját, prototípusát adhatjuk meg, a definíciót, a függ- 
vénytörzset az osztálydeklaráción kívül helyezzük el. Ilyenkor azonban név- 
ütközés fordulhat elő, hiszen két különböző osztálynak is lehet azonos nevű és 
paraméterlistájú tagfüggvénye, és ekkor a fordító nem tudná, melyik törzs 
melyik osztály függvényéhez tartozik. Ezért felhasználjuk az úgynevezett ha- 
tókör (scope) operátort, amelyet dupla kettőspont jelöl. Az osztály nevét és a 
hatóköroperátort a függvény neve elé írva tudatjuk a fordítóval, hogy a Point 
osztályon belüli setX és setY függvényről van szó. A függvények esetén az ar- 
gumentumok nevét elég csak a definíciónál megadni, a deklarációnál lehet, de 
nem kötelező.!0 

Mivel a függvény is a struktúra tagja, ezért a tagváltozókhoz hozzáférhe- 
tünk, mintha globális változók lennének. Példánkban az x és y változókhoz 
közvetlenül hozzáférhetünk a setX, illetve a setY tagfüggvényekben. 





10 Ha előírt argumentumlistájú függvényt kell megvalósítanunk, és a függvény törzsében 
nem használunk egy argumentumot, akkor egyáltalán nem kötelező megadni ennek az 
argumentumnak a nevét. Például: void fu(int). Tipikusan ilyen a postfix tt operátor pa- 
ramétere, amelyet csak a prefix operátortól való megkülönböztetés miatt kell megad- 
nunk. Ezt a 6.4. Speciális operátorok túlterhelése fejezetben tárgyaljuk. 
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ü ? "ta -ozókétól. Míg a tagváltozók 
A tagfüggvények megvalósítása eltér a tagváltozókétól. y 

annyi példányban jönnek létre, ahány váltózót hozunk létre a TÍZ ESASÁAÁRNA a 
tagfüggvények csak egyetlen példányban jönnek létre a memóriál 0 ogyan 
tudja akkor a függvény, melyik változó adattagjait kell módosítani? A tag- 
függvény implementációja nagyon hasonlít a C-ben írt bevezető példánkban 
használt megoldáshoz. A Ctt függvényeknek van egy láthatatlan első pa- 
raméterük, amely megkapja a módosítandó struktúrát. Mivel a tagfüggvény 
módosíthatja is a tagváltozókat, az átadás pointeren keresztül történik. Ezt 
az alábbi ábra mutatja a mi példánkra levetítve. 





Point pt; Point p2; 


Ed 


AES S Bi 
void Point::SetX(0, int value)  p1.SetX(100); 
void Point::SetY(a, int value)  p2.SetY(400); 

VE SES Esz] 


3. ábra. A tagfüggvények és a láthatatlan első paraméter 


A pl.setX(100) esetén a p1-re mutató pointer lesz a láthatatlan első paramé- 
ter, és annak az x tagváltozóját fogja módosítani a setX függvény. Vagyis a 
C44 fordító a bevezető C példához nagyon hasonló működésű kódot generál, 
és ezzel az egyszerű átalakítással szintaktikailag is lehetővé teszi az egységbe 
zárás magas szintű koncepcióját. 

Hogyan érhetjük el ezt a láthatatlan pointert? Erre szolgál a this kulcs- 
szó, amelyet példánkban egy Point" típusú mutatóként kezelhetünk. Említet- 
tük, hogy a struktúra tagváltozóira a tagfüggvényben a nevükkel hivatkozha- 
tunk. De mi történik, ha van egy ugyanolyan nevű tagváltozónk és függvény- 
argumentumunk? Ekkor az argumentumok és a lokális változók nevei , erő- 
sebbek", mint a tagváltozók nevei, vagyis elrejtik azokat. 








3.3. Adatrejtés 


Példánkban az x változónév ezért az argamentumként kapott x-et jelöli, így a this 
pointer segítségével hivatkozunk a tagváltozóra. Ugyanez érvényes, ha a tagvál- 
tozóval azonos nevű lokális változó esetén szeretnénk hivatkozni a tagváltozóra. 

A változók és a függvények egységbe zárását a Ct-t a struktúra koncepció- 
jának a továbbfejlesztésével érte el. Láttuk, hogy a tagfüggvények bevezeté- 
sével az adatok és a rajtuk végzett műveletek egy helyre kerültek, ami átlát- 
hatóbb kódot eredményez, de valamivel több feladatot ró a fordítóra. A követ- 
kezőkben szakítunk a struktúrával, hogy az adatrejtésre még hatékonyabb 
nyelvi elemet, az osztályt vezessük be. Ugyanakkor a struktúra itt leírt tulaj- 
donságai az osztályokra is érvényesek maradnak. 





3.3. Adatrejtés 


Láttuk, hogy az egységbe zárás alapelve áttekinthetőbbé, könnyebben kezel- 
hetővé tette a példánkat, de az egységbe zárás lehetőséget ad egy további 
alapelv, az adatrejtés (data hiding) bevezetésére is. Tételezzük fel, hogy az 
előző példában bemutatott Point struktúrát készítő és felhasználó programo- 
zó nem azonos. A Point struktúrát felhasználó programozót senki sem akadá- 
lyozza meg, hogy az alábbi kódrészletet leírja, lefordítsa, majd futassa: 








MEKROTETHE 27 SSE EÁ 065 antogjét táji 
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Ez azért problémás, mivel az x tagváltozónak mindig kisebbnek kellene len- 
nie, mint a MAX X makro. Ezt a helyzetet úgy jellemezhetjük, hogy a p in- 
konzisztens állapotba került, hiszen ha a Pointnak lenne olyan függvénye, 
amely kirajzolja azt egy MAX X"MAX Y méretű koordinátarendszerben íti- 
pikusan a képernyőn), akkor az a függvény arra számítana, hogy a pont ben- 
ne van a képernyőn megjeleníthető pontok tartományában, holott ez nem 
igaz. Ez a probléma könnyen megoldható lenne, ha a p változó adattagjait 
csak a tagfüggvényekből lehetne elérni, kívülről nem. Így a Point típus fel- 
használója arra lenne kényszerítve, hogy csak a setX, illetve a setY függvé- 
nyeken keresztül módosítsa az x és az y tagváltozót. Egészen pontosan erre 
szolgál a private kulcsszó, amelyet a struktúra definíciójában helyezünk el. 
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3. fejezet: Objektumok és osztályok 


nt után felsorolt tagváltozók és 
Apjivató kéüléssző és BE E Stt d orcrálátnatát ami jelen esetben gya- 
függvények csak az osztályon belül leszne MGbgáld j 
ű üggvényeket jelenti. Visszatérve az előbbi pél ához, a p.x ki- 
korlatilag a tagfüggv jvát tagváltozó. mert fordítási hibát kapunk. 
tejesen MENÉS örs KE MÉNÁS is igaz. A private kulcsszó ellentéte a 
Tzbii öz sétjelenői hogy az adott tagváltozó, illetve tagfüggvény a struktú- 
hr belülről és a struktúrán kívülről (más struktúrák tagfüggvényiből és glo- 
bális függvényekből) is hozzáférhető. Példánkban a x és azy tagváltozó pri- 
vát, a tagfüggvények publikusak. Ennek oka, hogy mindkét tagváltozó érté- 
kére (MAX X, MAX. Y) maximumot szabtunk meg. Ezt a kényszerfeltételt 
csak úgy tudjuk érvényesíteni, ha a változókat priváttá tesszük, és az őket 
módosító publikus tagfüggvényekben ellenőrizzük a kényszerfeltételeket. Ha 
az unsigned int értelmezési tartománya megfelelt volna nekünk, akkor publi- 
kussá tehettük volna a tagváltozókat, bool típusú változók esetében ez nem is 
ritka. Mivel a privát tagváltozókhoz nem férhetünk hozzá, két lekérdezőfügg- 
vényt is írnunk kellett (getX, getY). ét ösak 
Mindazonáltal a gyakorlati esetek többségében a tagváltozók általában 
privátak, és a struktúrán kívülről függvényekkel változtathatjuk őket. Ez azt 
is jelenti, hogy a gyakorlati esetekben gyakran szerepelnek kényszerfeltéte- 
lek, amelyeket a tagváltozók módosításakor csak függvényekkel tudunk el- 
lenőrizni. A másik ok abban rejlik, hogy a tapasztalt programozók csak annyi 
tagváltozóhoz, illetve tagfüggvényhez engednek hozzáférést, amennyihez fel- 
tétlenül szükséges. Ezt az elvet nem tükrözi kellően a struktúra szabályozá- 
sa. Eddigi példáink során ugyanis, ha nem írtuk ki a public, illetve a private 
láthatóságot szabályozó kulcsszavak valamelyikét, a publikusság volt az alap- 
értelmezett. Ezért futottak az eddigi példáink, és ezért tudunk használni egy 
C nyelven megírt struktúrát Ct- nyelvű programjainkban minden különö- 
sebb változtatás nélkül. Viszont az objektumorientáltság elveit jobban támo- 
gatja egy olyan nyelvi konstrukció, amely alapértelmezésben (ha nem írunk 
láthatóságot előíró kulcsszót) privátnak veszi a tagváltozókat és a tagfüggvé- 
nyeket. Így jutunk el az osztály C--4-beli implementációjához. Az osztály és a 
struktúra közti különbség mindössze az alapértelmezett láthatóságban rejlik. 








fe e e 3 





Az osztály — a struktúrához hasonlóan — egy típus, amelyből, ha fel szeret- 
nénk használni, változót kell deklarálni. Ennek a változónak a létrehozását 
az adott osztály példányosításának (instantiation) nevezzük, amelynek 
eredménye az osztály egy példánya. Az osztály egy példányát, vagyis a létre- 
jött változót objektumnak nevezzük. Példánkban a p2 egy Point típusú ob- 
jektum. Fontos újra hangsúlyoznunk, hogy az osztály egy típus, így például 
az int beépített típussal analóg. Mint ahogy az int típusból létre kell hoznunk 
egy változót, ha használni akarjuk, úgy az osztályt is példányosítjuk. Ezért 
esetünkben a Point.x-3 teljesen hibás lenne, hiszen az int-3 kifejezésnek 
sincs értelme. 


Útmutató: Amikor Cs: nyelven programozunk, használjunk mindig osztályt, a struktúrát csak 
korábbi C nyelvű kód beépítése esetén alkalmazzunk! 
Kövessük a hagyományos Cs kódszervezést, vagyis az osztálydefiníciót osztálynév.h állo- 


mányba, az osztályon kívül definiált függvényeket osztálynév.cpp állományba helyezzük el!" 


Mivel egy osztályt több osztály is felhasználhat, érdemes megelőzni, hogy a .h 
állomány által tartalmazott osztálydefiníció többször is be legyen építve 
(include) egy forrásállományba. Ezt az ttifndef direktívával érhetjük el: 








u A konvenciókban vannak eltérések. A fejlécállomány lehet App vagy hax kiterjesztésű, 
vagy egyáltalán nem tartalmaz kiterjesztést, ez utóbbit alkalmazza a szabványos CH 
könyvtár. A epp kiterjesztés helyett találkozhatunk exx, et-t kiterjesztésekkel is. 
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Vagyis hogyha még nem definiáltuk a POINT. H makrót, akkor definiáljuk, 
és beépítjük az osztálydefiníciót. Amikor másodszor szeretnénk beépíteni a 
Point.h állományt, akkor már definiálva lesz a POINT.H makró, és a feltétel 
kiszűri az osztálydefiníciót. Így a fordító nem ad hibaüzenetet többszörös de- 


finíció miatt. 


3.4. Konstruktorok és destruktorok 


Az objektumorientáltság jegyében eddig elértük, hogy a Point osztály tagvál- 
tozói és tagfüggvényei egy helyen vannak. A másik eredmény, hogy az osztály 
tud magára vigyázni: az osztály logikájából fakadó kényszerfeltételeket (pél- 
dául az x tagváltozó értékének korlátozása) képesek vagyunk betartatni tag- 
függvények segítségével, és ezzel együtt a tagváltozókhoz való hozzáférést is 
szabályozhatjuk. Objektumaink most már csak egy helyen sebezhetőek: a lét- 
rehozásnál. Vegyük az alábbi példát: 





A fenti példában ki szeretnénk rajzolni a é ü iraj 
Pontot, tételezzük fel, hogy a kiraj- 

at végző més. függvény rendelkezésre áll. Mivel az objektum létrejöttétől 
késön E adtunk értéket a tagváltozóknak, azok véletlen értékeket tartal- 
ak, mint minden más ini. tlan C és C4-- változó. Jó lenne, ha le- 





Példánkban a Point() függvény a konstruktor. Mivel mindössze annyi a fel- 


adata, hogy lenullázza a tagváltozókat, ezért az osztálydefinícióban adtuk 
meg a törzsét. Nézzük meg, hogyan futtathatjuk le a konstruktort. 


Ekkor automatikusan meghívódik a fent megadott konstruktor. Itt említjük 
meg, hogy a konstruktort függvényhez hasonlóan meghívni nem lehet, csak 
az automatikus meghívódását , kényszeríthetjük kí" a fenti módon. 


Útmutató: Sose hívjunk konstruktort tagfüggvényhez hasonlóan, ugyanis a működése telje- 
sen más lesz, mint amit egy tagfüggvénytől várunk. "? 





Az eddigi konstruktor lenullázta a tagváltozókat. Ezzel azt érte el, hogy az 
objektum létrehozásakor érvényes állapotba kerüljön. Ugyanakkor ha egy 
adott koordinátájú pontot szeretnénk létrehozni, az akár még két függvény- 
hívásba is kerülhet: 





Ez a hatékonyságot is rontja: először lenullázzuk a tagváltozókat, majd érté- 
ket adunk nekik. A függvénynév túlterhelése a konstruktorra is igaz: így egy- 
szerre több, különböző paraméterlistájú konstruktort is megadhatunk. 








12 Részletes magyarázatot a 8.2.1. Konverzió független típusok között fejezetben találunk. 














3. fejezet: Objektumok és osztályok 
A konstruktor paramétereit a létrehozáskor adhatjuk meg: 


HENTES ZEJ FEEL BKSSBZ SZERESSENEK ELTE 1-5 TET 


Ha fentiekben bemutatott argumentum nélküli konstruktort szeretnénk 
meghívni, a már bemutatott módon el kell hagynunk a zárójeleket. Üres 
zárójelek nem megengedettek, vagy a fordító teljesen másképp értelmezi őket 
(például függvénydeklarációként). Az argumentum nélküli konstruktor neve 
alapértelmezett konstruktor (default constructor), az egyargumentumú konst- 
ruktoré — később, a 8.2.1. Konverzió független típusok között fejezetben részle- 
tezendő okok miatt — konverziós konstruktor (conversion constructor). 

Ha egyáltalán nem írunk konstruktort, akkor az osztály automatikusan 
tartalmaz egy alapértelmezett konstruktort, amely nem csinál semmit. Ezt 
hívtuk a konstruktorok bevezetéséig. Viszont ha legalább egy konstruktort 
definiáltunk, akkor csak az általunk megírt konstruktorokat paraméterezve 
lehet egy osztályt példányosítani, ha nem írunk külön alapértelmezett konst- 
ruktort, akkor létrehozáskor nem adhatunk meg üres argumentumlistát. 





A fenti kódrészletben definiáltunk konstruktort, méghozzá egyet, ezért csak 
azon keresztül lehet egy Point típusú objektumot létrehozni. 





Az alapértelmezett függvényargumentumokkal vi é h. 
eldhatsák tl viszont két konstruktor he: 








3.5. Dinamikus adattagot tartalmazó osztályok 





Így mindhárom példányosítás helyes: 





A beépített típusoknak is van konstruktoruk, amelyet inicializáláshoz hasz- 
nálhatunk. Az alapértelmezett konstruktor természetesen működik, az egy- 
argumentumú konstruktor lehetővé teszi az inicializálás konstruktorhívással 
egyező szintaxisát: 


A fenti két sor teljesen ekvivalens. Itt jegyezzük meg, hogy az egyargumen- 
tumú konstruktorok hívására általában is igaz, hogy választhatunk az egyen- 
lőségjeles vagy a konstruktorhívásos szintaxis között.13 Ezek a szintaktikai 
részletek logikussá válnak, ha figyelembe vesszük a C--t típustámogatás 
alapelvét: ha egy int típusú értéket inicializálhatunk így, akkor egy osztályt is. 

Míg az inicializálást a konstruktor végzi, az objektumok által birtokolt 
esetleges erőforrások felszabadítását pedig a destruktor (destructor). A dest- 
ruktor tagfüggvény, egy - jellel kezdődik, amelyet az osztály neve követ. 
Destruktort nem kötelező írni, és sosincs paramétere. A destruktor akkor hí- 
vódik meg, ha az objektum megszűnik: felszabadítjuk, vagy a vezérlés elhagy- 
ja azt a blokkot, ahol létrehozták. A destruktor alkalmazásához viszont új 
esettanulmányra van szükségünk. 









3.5. Dinamikus adattagot tartalmazó osztályok 


JENSEN EE ÉGE RARÉSSE S SBS MET MTE A TEV EE TT 
Feladat: írjunk egy olyan tárolót, amelybe egész típusú értékeket (int) tehetünk be, illetve 


vehetünk ki olyan sorrendben, amilyen sorrendben beraktuk őket. Mivel az először belerakott 
elemet vehetjük ki elsőként, ezt a struktúrát first in, first out (FIFO) tárolónak nevezzük. 


Mivel a tároló maximális méretét nem adtuk meg, addig tehetünk bele ele- 
meket, amíg képes memóriát foglalni nekik. Ehhez a dinamikus memóriake- 
zelésre van szükségünk. Ezért elsőként megvizsgáljuk a dinamikus memória- 
kezelés témakörét, majd lépésről lépésre megoldjuk a feladatot. Ennek során 
számos új nyelvi elemmel ismerkedünk meg, amelyek némileg csökkentik a 
dinamikus memóriaterület kezelésének C-ben tapasztalható veszélyeit. 





15 A két forma közti különbséget a §.2.1. Konverzió független típusok között fejezetben rész- 
letezzük. 


31 














3. fejezet: Objektumok és osztályok 
3.5.1. Dinamikus memóriakezelés 


C-ben a dinamikus memóriakezelést a malloc és a free függvényekkel, vala- 
mint ezek variánsaival végezhettük. 






/"memóriaterület lefoglalása"/ 
ánt. "pint - Cint") c 


/sa pint által mutatott terület felhas 
free(pint); /"A lefoglalt terület felszabadítása"/ 


Emlékezzünk vissza, hogy a Ct--ban az inicializálás során kezdeti értékek 
megadását írhatjuk elő. Jól látható, hogy a malloc függvény egyáltalán nem 
tud arról a típusról, amelynek helyet foglal, hiszen csak a lefoglalandó terület 
méretét tudja bájtokban megadva. A malloc tehát szintaktikájánál fogva al- 
kalmatlan további paraméterek átvételére, illetve imnplementációjánál fogva 
alkalmatlan objektumok inicializálására, ami konkrétan a megfelelő konst- 
ruktor meghívását jelenti. A paraméterátadás miatt a Ct4-ban már nem is 
függvény, hanem operátor felelős a dinamikus memóriakezelésért. Ennek az 
operátornak a neve new, és a precedenciáját az , A" függelék tartalmazza. Az 
alábbiakban létrehozunk és felszabadítunk egy egész típusú változót: 


intt p; més 
Pp - new int; 

// Itt használjuk a válti 
$p s 10; 

delete p; 


Jól látható, hogy itt nem kell bajlódnunk a konvertál 
típusra mutató pointerrel tér vissza. A használat ut. 


delete operátorral szabadíthatjuk fel. A new operátori 
nyosíthatunk: 


ással, a new a lefoglalt 
án a lefoglalt helyet a 
ral osztályokat is példá- 


Point pPGÍNt E fék POIGEO: 
//dasználjuk az objektumot; 





konstruktor hívását eredményezi. Ha a 


konstruktorával inicializáljuk, akkor a paramé- 
árójelben tüntetjük fel: 


Point osztályt kétparaméterű 
tereket az osztály neve után z. 
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Fo  — 1.5. Dinamikus adattagot tartalmazó osztályok. 


Ha a paraméter nélküli konstruktorral inicializáltatjuk az objektumot, kétfé- 
le szintaxist is használhatunk: elhagyhatjuk a zárójeleket, mint ahogy az 
egész típusú változó lefoglalásánál tettük, vagy kiírhatjuk az üres zárójeleket, 
amint azt a Point osztály példányosítása mutatja. A delete operátor természe- 
tesen meghívja a felszabadítandó objektum destruktorát. 

Mivel a C malloc függvénye bájtokban vette át a lefoglalandó hely mére- 
tét, egy szorzással könnyű volt tömbök számára helyet foglalni. A típusos neiv 
operátor esetén erre nincs lehetőség, viszont számolgatnunk sem kell. Töm- 
bök lefoglalását a nagyon hasonló nevű new ( ] operátorral végezhetjük, il- 
letve a lefoglalt területet a delete [] operátorral szabadíthatjuk fel, 


Ilyenkor nem adhatunk meg külön konstruktorparamétereket, a tömb tagjai 
az alapértelmezett konstruktorokon keresztül inicializálódnak. Így ha a pél- 
dányosítandó osztálynak alapértelmezett konstruktora, akkor nem tudunk 
belőle tömböt lefoglalni. Jóllehet ezek az operátorok nagyon hasonlítanak a 
szögletes zárójel nélküli megfelelőikre, valójában különböző operátorok. Gon- 
doljunk a két --- operátorra (prefix és postfix), amelyek szintén nagyon hason- 
lóak, mégis másképpen működnek. Ezért mindig tartsuk be az alábbi szabályt! 


Útmutató: Azokat a memóriafoglalásokat, amelyeket a new operátor szögletes zárójel nél- 
küli változatával foglaltunk, a delete operátor zárójel nélküli változatával szabadítsuk fel. Ha- 
sonlóan, ha szögletes zárójelet tartalmazó new operátorral foglaltuk le a memóriát, a záróje- 
les delete operátorral szabadítsuk fel a lefoglalt területet. 


Ha nem tartjuk magunkat a fenti útmutatáshoz, annak memóriaszivárgás, 
vagy rosszabb esetben nem definiált működés! lehet a következménye. 

Ha olyan objektumot próbálunk felszabadítani, amelyet nem dinamiku- 
san foglaltunk le, a művelet eredménye nem definiált. Kivételt képez a 0 ér- 
tékű pointer, amely esetén a delete, illetve a delete/ ] semmit sem csinál. 

A memóriafoglalás során fellépő hibák kezeléséről a 10.2.2. Kivételhie- 
rarchiák részben lesz szó bővebben. 





u A new és a delete operátorok, illetve szögletes zárójelet tartalmazó változataik ugyanis 
tagfüggvényként váltazhalheták (lásd 6.5. Általános szabályok fejezet), és a lefoglalást 
végző operátorok a lefoglalt területen a felszabadításra vonatkozó egyéni információt he- 
lyezhetnek el, amelynek az operátorok összecseréléséből adódó félreértelmezése komoly 
hibához vezethet a terület felszabadításakor. 
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3. fejezet: Objektumok és osztályok 
3.5.2. Dinamikus adattagok támogatása 


Ezek után rátérhetünk kitűzött feladatunk megoldására: ESÁKKZÉTÉ a 
inamikus FIFO osztályt. A tároló egész típusú értékeit egy pointerrei (data) 
ván leten tartjuk. Egy lehetséges megvalósítás pél-. 
dául a következő. Akárhányszor új elem kerül a FIFO-ba, a JENEÜS terüle- 
tet eggyel meg kell növelnünk. Ezért lefoglalunk egy eggyel nagyobb méretű 
területet, átmásoljuk az eddigi adatokat, és a végéhez fűzzük az újonnan be. 
letett elemet. Amikor kiveszünk egy elemet (ez a FIFO tulajdonság miatt 
csakis az első elem lehet), akkor egy eggyel kisebb memóriaterületet fogla- 
lunk, az első elemet visszaadjuk, és átmásoljuk a benn maradt elemeket. 
Mivel van egy pointerünk, amelynek segítségével dinamikus adatterüle- 
tet foglalunk, óvatosan kell eljárnunk, hiszen a lefoglalt memóriaterületet fel 
kell szabadítanunk. Ezen a ponton mutatkozik meg az egységbe zárás és így 
az objektumorientált gondolkodásmód igazi ereje. Emlékezzünk vissza, hogy 
a destruktor olyan függvény, amely automatikusan meghívódik, amikor az 
objektum megszűnik. Ezért a destruktorban mindig felszabadíthatjuk a mu- 
tatott területet, és mivel a destruktor automatikusan meghívódik, ez a fontos 
művelet nem fog , elfelejtődni". Említettük viszont, hogy ha a delete operáto- 
rokat olyan nem nulla értékű pointerre hívjuk meg, amelyet nem valamelyik 
new operátor foglalt le, kiszámíthatatlan lesz a programunk működése. Ezért 
nagyon fontos, hogy a kezdetektől fogva konzisztensen tartsuk a mutató álla- 
potát: ha NULL, akkor nincs lefoglalt adat, ellenkező esetben pedig egy, ese- 
tünkben a newf/ ] operátorral lefoglalt területre mutat. Az objektum létrejöt- 
tekor a konstruktor biztosítja a megfelelő kezdeti értéket, és a pointert az 
elemeket betevő és kivevő függvények tartják konzisztensen. Ezt az egységet 
megbontaná, ha kívülről , avatatlan kezek" módosítanák a pointer értékét, 
vagyis a data nevű pointerünk privát tagváltozója lesz az IntFifo osztálynak. 
Az elemek nyilvántartására természetesen nem elég egyetlen pointer: tud- 
nunk kell, hogy mennyi elem van éppen a FIFO-ban. Ezt szintén egy privát 
változóban (count) tartjuk számon, amelyet a konstruktorban inicializálunk, 
és az elemek betevésekor, illetve kivételekor változtatjuk. 

7 A fenti elgondolás működne, ugyanakkor nem a leghatékonyabb megol- 
dás, hiszen minden változáskor újra kell foglalni a memóriát. Erre a szokásos 
jEzsú sanbjó LENNRISSÉBK BEA tároló felhasználója megad egy maximális 
mm A ee ed eteó nűsíbetően nem halad meg a tárolandó elemek 
in hálót via GYE ÉSESZEÉSZE a megadott elemszámnak megfelelő mé- 
megadott E He ekkora helyet mindig lefoglalva tart. Ha viszont a 

éretnél több elemet tartalmaz a tároló, akkor mindig nőni, illetve 


csökkenni fog a lefoglalt memória mérei ÜTÉSRE 
5 mérete, KB ral 
kivettünk egy elemet. érete, attól függően, hogy betettűnk vagy 


fémjelzett dinamikus adatterül 











3.5. Dinamikus adattagot tartalmazó osztályok 


IntFifo fifot; 


Dinamikusan lefoglalt memória az elemeknek 


4. ábra. Az IntFifo objektumok memóriaképe 


Ezen megfontolások alapján az IntFifo osztály definíciója az alábbi: 


class IntFifo 
í 
// Mutató az elemeknek lefoglalt hely elejére 
int: data; 
// A FIFO számára lefoglalt memória alapértelmezett mérete 
// elemszámban 
unsigned int size; 
// A FIFO-ban aktuálisan levő elemek száma 
unsigned int count; 
public: 


// Konstruktor 
IntFifoO; 


// konstruktor, a FIFO mérete adható meg paraméterben 
IntFifo(unsigned int size); 


// Másolókonstruktor 
IntFifo(const IntFifog fifo); 


// Destruktor 
-IntFIfoO; 


// Berak egy elemet a FIFO-ba 
void PutCint item); 


// kivesz egy elemet a FIFO-ból 


// true-val tér vissza, ha sikerült az elem kivétele, false-szal 


// egyébként 
bool Get(Cinté item); 


// kiírja a FIFO tartalmát 
void PrintO; 


// visszatér a FIFO-beli elemek számával 
int count íreturn countgb [7 nézés 







// Igaz, ha a FIFO üres 
bool IsEmptyOíreturn count : 
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3. fejezet: Objektumok és osztályok 
plementációját! Nézzük először az 


Vegyük most sorra az egyes függvények imi 
inicializálást: 





Az alapértelmezett konstruktor egy üres FIFO-t hoz létre. Az egy int típusú 
argumentumot váró konstruktor beállítja a count változót nullára, hiszen ki- 
induláskor nincs egy eleme sem a FIFO-ban. A size paraméterben megkapott 
értéket a size tagváltozóba tölti, és ha az nem nulla, az értékének megfelelő 
nagyságú helyet foglal a memóriában. Ha a size nulla, a data értéke is NULL, 
egyébként a lefoglalt memóriarészre mutat. 

A destruktor egyszerű: 











Egy elem betételénél két alapvető esetet kell megkülönböztetnünk: 


e ha beletesszük az elemet a tárolóba, a tároló mérete meghaladja az 
előre lefoglalt méretet; 


e a tároló mérete az új elemmel együtt nem haladja meg az előre lefog- 
lalt méretet. 


Az első esetben az alábbi lépésekre van szükség. 
e Le kell foglalni egy eggyel nagyobb méretű tömböt, amelyre egy ideig- 
lenes pointerrel (temp) hivatkozunk. 


e Egy ciklussal átmásoljuk az eddigi adatokat az újonnan lefoglalt 
tömbbe. 


e  Hozzáfűzzük az új elemet a tömb végére. 

e — Felszabadítjuk az eredeti tömböt. 

e A data pointert az újonnan lefoglalt területre irányítjuk. 
A második eset jóval egyszerűbb: itt csak hozzáfűzzük a tömb végére az új 
elemet, hiszen van elég lefoglalt memóriánk. 

Egy elem kivételénél a fenti megkülönböztetéseken kívül más esetek is 
előfordulnak: 

e  atároló üres, 


e az elem kivételével a tároló még mindig a size által meghatározott 
memóriaméret felett van, 


s az elem kivételével a tároló elemeinek száma nem haladja meg a size 
változó értékét. 


Az első esetet könnyen tudjuk kezelni: hibával térünk vissza. A második eset 
valamivel összetettebb. Elképzelhető ugyanis, hogy a size értéke nulla, így az 
elem kivételével kiürül a tároló. Ilyenkor a data értékét NULL-ra kell állíta- 
nunk, a count értékét pedig nullára. Ellenkező esetben az alábbi lépéseket 
kell végrehajtani: 
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3. fejezet: Objektumok és osztályok 


e — a tömb legelső elemét adjuk vissza majd referencián keresztül; 


e. lefoglalunk egy eggyel kisebb méretű tömböt, majd a bennmaradó 
elemeket belemásoljuk; 
e — felszabadítjuk az eredeti tömböt; 


e — adata pointert az újonnan lefoglalt területre irányítjuk. 





A harmadik esetben mindössze eggyel előrébb csús: atjuk a tömb elemeit, hi. 
szen ha az elemek száma kisebb, mint a size változó értéke, akkor nem szaba- 
dítjuk fel az elemek helyét, csak a count változó csökkenése jelenti a változást. 





bool IntFifo::GetCinté item) 


tj 
if (count —— 0) 


fprintf(stderr, "Data reguest from an empty Fifo.m"); 
return false; 
3 


item - data[0]; 
--count; 
if(size cz count) // Eggyel összehúzzuk a dinamikus tömböt 


// Ha már csak egy elem van... 
if(count -—— 0) 


delete[] data; 
data - NULL; 
return true; 


int: temp - new int[count]; 
forCunsigned int i - 0; i c count; 144) 
templi] - data[Ci41]; 


delete []data; 
15, data — temp; 





A megírt osztályt pedig az alábbi módon használhatjuk fel: 
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A két lekérdezőfüggvény (Count, IsEmpty) nem különösebben bonyolult, azért 
kellett megírnunk őket, mert a count változó nem publikus. A harmadik 
konstruktor ugyanakkor annyira fontos szerepet tölt be, hogy vele külön fog- 
lalkozunk. 


3.5.3. A másolókonstruktor 


Példánkban az IntFifo(const IntFifog fifo):5 tagfüggvényt másolókonstruk- 
tornak (copy constructor) hívjuk. Ismérve, hogy egy referenciát vár, amelynek 
típusa megegyezik az osztály típusával. A másolókonstruktor is rendelkezik 
azokkal a lehetőségekkel, amelyekkel az összes többi konstruktor: létreho- 
záskor inicializálhatjuk vele az objektumainkat. A másolókonstruktor eseté- 
ben az újonnan létrehozott objektumot egy már meglevő objektum alapján 
inicializáljuk, célunk egy másolat létrehozása. 


IntFifo fifo(3); 
IntFifo fifo ; 
// vagy a C-ben 

IntFifo fif. 
IntFifo fifo2 — 








A másolókonstruktornak ugyanakkor van egy másik funkciója. Amikor érték 
szerint adunk át egy függvényparamétert, akkor mintegy a függvényhívás ré- 
szeként lemásolódik az átadott változó, a függvénytörzsben azt használjuk, 
majd amikor kilépünk a függvényből, akkor felszabadul. Ezt a fordító auto- 
matikusan megoldja helyettünk. Ebből adódik az a megszokott viselkedés, 
hogy érték szerinti paraméterátadás esetén a függvény törzsén belül végre- 
hajtott változtatások egyáltalán nem érintik az argumentumként átadott vál- 
tozót. Ha azt szeretnénk, hogy az átadott érték változzon, akkor C-ben poin- 
tert adunk át, C-t--ban referenciát (2.4. Paraméterátadás referenciatípussal 
rész), ez esetben ugyanis nem történik másolás: a pointer, illetve a referencia 
felhasználásával az eredeti változón, illetve objektumon dolgozunk. 

A másolás a beépített típusok esetén egyszerű feladat: a fordító tudja például 
az int típusú változó méretét, tudja a helyét a memóriában, így nincs más dolga, 
mit , bitenként" átmásolni az adott című és méretű memóriaterületet. Természe- 
tesen ezt a műveletsorozatot struktúrára, sőt, objektumra is el lehet végezni, és 
ez sokszor teljesen meg is felel a várakozásainknak. A fenti FIFO osztály esetén 
azonban , érdekes", pontosabban nemkívánatos működéshez vezet. 





15. A const kiírása nem kötelező, de ajánlott, A konstansokkal részletesen a 4. Konstansok és 
inline függvények fejezetben foglalkozunk. 
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Az alábbi ábrán látható a másolás eredménye: mindkét objektum data poin- 
tere ugyanarra a memóriaterületre mutat. 


Dinamikusan lefoglalt memória az elemeknek 





5. ábra. A bitenkénti másolás eredménye 


Födtsget körtét Erdő nbitenként" másolja az objektumot. Tudja az egyes 
töljeéhő selő FREJKEN EÉNESSA és átmásolja. Amikor a pointerhez érkezik, 
uk Naa az JADE el 32 bites érték, tudja a címét, majd átmásolja a tar- 
jelent, azzal ÉHEK e kezés SÉT az a tartalom éppen egy memóriacímet 
pointer fémjelez. 8 még kevésbé, hogy azt a dinamikus adattagot, amelyet a 
kell: a FIFO VELOS le kellene másolni. A fordító nem is tudná hogyan 
ÜNÖJÁKEKÜTKÉ LA emeinek mérete a futás során állandóan változik, nem 

5! időben, hogy mekkora a data pointer által mutatott memória- 


terület i ji 
e mérete. Azt pedig nem várhatjuk a fordítótól, hogy rájöjjön, hogy mi a 





3.5. Dinamikus adattagot tartalmazó osztályok 


meg, hogy a ,bitenkénti" másolás neve sekély másolás (sAhallow copy), míg 
amikor a dinamikus adattagokat is lemásoljuk, mély másolásról (deep copy) 
beszélünk. Nézzük most meg, hogyan kell megírni a mély másolást, vagyis 
hogyan implementáljuk mi a másolókonstruktort! 

A másolókonstruktor deklarációja az alábbi: 


Ilyenkor a másolókonstruktornak átadott argumentumból kell egy másolatot 
létrehozni. Ez logikus is, hiszen a függvényparamétert inicializáljuk az át- 
adott értékkel. 

Az alábbi ábra mutatja a kívánt másolást. 


Dinamikusan lefoglalt memória az elemeknek 





Dinamikusan lefoglalt memória az elemeknek 


femlem[-]T ] 





6. ábra. A másolatkészítés kívánt eredménye 
Így a feladatunk az alábbi lépésekben foglalható össze: 


s  AcountÉés a size paramétereket átvesszük a kapott fifo objektumtól. 
e — Ha a fifo üres, a data értékét NULL-ra állítjuk. 


e. — Ellenkező esetben meghatározzuk az aktuális lefoglalandó méretet, 
amely a size és a count közül a nagyobbik (actualSize). Lefoglalunk egy 
actualSize méretű tömböt, és átmásolunk count darab intet a fifo.data 
pointer által mutatott memóriaterületről. 


Így a Ct-t kód a következő lesz: 
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Érdemes megfigyelnünk, hogy közvetlenül hozzáférhetünk egy másik objek- 
tum privát adattagjaihoz. Ez nem meglepő, hiszen a láthatóság osztályszin- 
ten és nem objektumszinten szabályoz. Emögött az húzódik meg, hogy ha az 
IntFifo osztályt írjuk, akkor tisztában vagyunk az IntFifo osztály belsejével 
is, így a privát tagok is hozzáférhetők. 

Vizsgáljuk meg egy pillanatra, mi lenne, ha nem írtunk volna másoló- 
konstruktort az IntFifo osztálynak, és a fent bemutatott módon meghívnánk 
az fv függvényt. A függvény törzsében megjelenő param úgy viselkedik, mint 
egy lokális változó, amely a main függvénybeli hívás alkalmával a fifo objek- 
tum sekély másolata. Vagyis mindkettejük data adattagja ugyanarra a címre 
mutat. Ha változtatjuk a data által mutatott adatterületet a függvény törzsé- 
ben a param változón keresztül, az a main függvénybeli fifo objektum dina- 
mikus területének megváltoztatását is jelenti, hiszen a data közös, viszont 
nem változtatná a fifo count tagváltozóját, ezáltal a fifo teljesen inkonzisz- 
tenssé válna. Az így kialakult helyzetet tovább súlyosbítja, hogy a lokális 
param objektum a függvényből való kilépéskor megszűnik, és meghívódik a 
destruktora, amely felszabadítja a data által mutatott közös adatterületet. 
MEgGÉn SZÁE a main függvénybe, a fifo azt hiszi, minden úgy van, 
k sában olt, de mi tudjuk, hogy az adattagját felszabadították. Ezek után a /ifo 

mát lekérdező és módosító függvények, valamint a destruktor érvényte- 
len (nem lefoglalt) adatterülettel dolgozik. 


ERR S ty  SSSS535385 


tort, még akkor i A 
e ztsszögzáélnn eredetileg nem szeretnénk érték szerint átadni függ- 


save a mást nem, csak egy olyat é DEZE 
v lyat érdi 38 ly ad egy 
hibajelzést, 26 hogy nem implementáltuk a lókonstsukta örE St később 


Kivételkezelés fejezet) szokás megat e "n9t implemented exception" kivétellel (lásd 10 
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véletlenül mégis átadjuk érték szerint, rögtön kiderül a hiba. A sekély és 
mély másolat problémájára még visszatérünk a 6.4. Speciális operátorok túl- 
terhelése részben. 

Emlékeztetünk arra, hogy referencia szerinti paraméterátadásnál nem 
hívódik meg a másolókonstruktor, érték szerinti paraméterátadásnál viszont 
igen. Ezért kell a másolókonstruktor paraméterét referencia szerint átadni. 
Ha a másolókonstruktornak érték szerint adnánk át a paramétert, akkor maga 
a másolókonstruktor hívásához is szükség lenne a másolókonstruktor hívásá- 
ra. Ezért az érték szerinti paraméterátadás végtelen rekurzióhoz vezetne. 


3.5.4. Összefoglalás 


Ebben a részben megismertük a dinamikus adattagokat tartalmazó osztályok 
kezelését. Láttuk, hogy az egységbe zárás alapelve, illetve az automatikus 
inicializálás és megszüntetés segítségével biztonságossá lehet tenni a dina- 
mikus memóriakezelést. Az ilyen típusú osztályok esetén megjelenik a sekély 
és mély másolat közti különbség, amely nemcsak a Ct- nyelven, de a moder- 
nebb programozási nyelveken (Java, Cst) is nemkívánatos jelenségeket okoz- 
hat. Általában a hiba rejtélyes: ,az objektum változik, pedig nem is változtat- 
tuk" észrevétel elsőre természetfelettinek tűnik, ilyenkor érdemes másolási 
hibára gyanakodnunk. A , félrepointerezés", vagyis amikor egy pointeren ke- 
resztül a program más részéből akaratlanul változtatjuk az adatot, szintén 
ilyen hibajelenséget produkál, de ezt — tapasztalataink szerint — ritkábban kö- 
vetjük el. A másolókonstruktor minden olyan esetben meghívódik, amikor nem 
pointerként vagy referenciaként adunk át objektumot, illetve így térünk vissza. 

Végül útmutatóban foglaljuk össze az eddig leírtak legfontosabb követ- 
kezményeit. 





Útmutató: Dinamikus adattagok esetén mindig tisztázzuk a felelősségeket! Ha egy memória- 
foglalást egy adott osztályban írunk meg, ott írjuk meg annak felszabadítását is! Ha viszont a 
konstruktorban vettük át paraméterként a dinamikus adattagot, akkor nem nekünk kell felsza- 
badítanunk, hanem annak az objektumnak, amelyik létrehozta. Így tudjuk a legjobban kihasz- 
nálni a konstruktor és adestruktor automatikus meghívódásának előnyeit. 

A mi felügyeletünk alá tartozó dinamikus adattagot tartalmazó osztály esetén mindig írjunk 


— — konstruktort, amely inícializálja a pointert; 
— — másolókonstruktort, amely vagy elvégzi a másolást, vagy hibaüzenetet ad; 


— destruktort, amely felszabadítja a pointer által mutatott területet! 
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3.fejezet: Objektumok és osztélyek mm 


3.6. Friend függvények és osztályok 
A Cs nyelvben lehetőség van rá, hogy egy osztály globális függvényeket, va. 
lamint más osztályok tagfüggvényeit feljogosítson arra, hogy saját védett 


(private, protected!7) tagváltozóihoz és tagfüggvényeihez hozzáférjenek. A to. 
vábbiakban ennek lehetőségeivel ismerkedhetünk meg részletesebben. 


3.6.1. Friend függvények 


Az egyes osztályok a friend kulcsszó használatával feljogosíthatnak globális 
függvényeket, illetve más osztályokhoz tartozó tagfüggvényeket a védett tag. 
jaikhoz való hozzáférésre. Az ilyen függvényeket friend (barát) függyé- 
nyeknek nevezzük. Egy osztály friend függvényeinek pontosan olyan hozzá. 
férési jogai vannak az osztály tagfüggvényeihez és tagváltozóihoz, mintha az 
adott osztály tagfüggvényei lennének. A friend függvények alkalmazását az 
alábbi kódrészlet szemlélteti: 





SEN 
A protected a private. bili 
majd csak Ég elesssássts és lichoz hasonló, láthatóságot szabályozó kulcsszó, amely 
Során nyer értelmet. tagfüggvények öröklése fejezetben ismertetett öröklés al- 





3.6. Friend függvények és osztályok 








A Point egy pont objektumok reprezentálására szolgáló osztály. A PrintPointX 
egy globális függvény. Ez a paraméterében megkap egy Point osztálybeli ob- 
jektumot, melynek x tagváltozóját kiírja a szabványos kimenetre. Az x tagvál- 
tozó a Point osztályban privát. Ez azonban nem okoz problémát, mert a Print- 
PointX függvényt a Point osztály friendnek deklarálta. A ,barátságba foga- 
dáshoz" az adott függvényt az osztálydefiníciós részben a friend kulcsszóval 
kell deklarálni. Bár a szintaktika nagyon hasonlít a közönséges tagfüggvé- 
nyek deklarálásához, a friend függvények megmaradnak globális függvé- 
nyeknek,!5 csak éppen speciális jogokkal rendelkeznek. A kódrészlet arra is 
mutat példát, milyen módon lehet egy adott osztály valamely tagfüggvényét 
barátnak deklarálni: a Point osztály a SpecPoint osztály Point8z argumentumú 
konstruktorát friendnek deklarálja, így a konstruktorban lehetőségünk van a 
Point védett tagjaihoz való hozzáférésre. 

Megjegyezzük, hogy esetünkben a Point osztály x tagváltozójának kiírásá- 
hoz a PrintPointX globális függvény bevezetése helyett sokkal szebb megoldás 
lett volna egy tagfüggvényt definiálni. Mint azonban később az operátorok túl- 
terhelése (6. Operátorok és túlterhelésük fejezet) kapcsán látni fogjuk, ez nem 
minden esetben tehető meg. Így a friend függvényeknek van létjogosultsága. 


3.6.2. Friend osztályok 


A friend osztályok koncepciója nagyon hasonlít a friend függvényekéhez. Ez 
esetben az osztályunk egy másik osztályt jogosít fel a védett tagjaihoz való 
hozzáférésre, így az az osztályunk friend (barát) osztálya lesz. A friend osz- 
tály tagfüggvényeinek pontosan olyan hozzáférési jogai vannak, mintha az 
adott osztály tagfüggvényei lennének. A friend osztályok alkalmazását az 
alábbi kódrészlet illusztrálja: 


15 Nem válnak az osztály tagfüggvényeivé, így az osztály objektumaira nem hívhatók (a . 
vagy -2 operátorokkal). 




















A Point osztály a FriendClass osztályt a friend kulcsszóval barátnak deklarálja, 
így a FriendClass osztály a PrintPointX tagfüggvényében hozzáférhet a Point 
osztály védett x tagváltozójához. 

A friend viszonyra vonatkozóan két fontos szabály létezik: 


e A friend tulajdonság nem öröklődik.19 Vagyis ha A osztály barátja B, 
akkor B leszármazottai nem barátai A osztálynak. Természetesen 
semmi akadálya nincs annak, hogy az A osztály a B osztály leszárma- 
zottait is explicit barátnak deklarálja. 


s A friend tulajdonság nem tranzitív. Ennek megfelelően, ha A osztály 
barátja B, és B osztály barátja C, akkor C nem barátja A-nak. Termé- 
szetesen itt is megoldható, hogy az A osztály a C osztályt is barátnak 
deklarálja. 


3.6.3. A friend viszony tulajdonságai 


Én ll lg alkalmazása azt az érzést keltheti bennünk, hogy ellentmond az ob- 
Jektum mint fekete doboz koncepciójának s így az adatrejtés elvének, mert 
hozzáférést biztosít az objektum belső állapotához. Ez általánosságban nincs 
én va HOZZáTÓKÉS A hozzáférni kívánt objektum által szabályozott módon 
vő HÉT Zéta káe més meghatározott függvények és ketes 
SÉTA E sVAt Janakkor EPZE S vi a 
gyakorlatban ritkénándokolt FANG ÉLSZKSB a friend túlzott használatát, 






esstisséséey e dope eg RA 
19. Az öröklés alapjaival a 7. 
tünk meg. alapjaival a 7.1.Tagváltozók és tagfüggvények öröklése fejezetben ismerkedhe: 


46 





3.7. Tagváltozók inicializálása 





3.7. Tagváltozók inicializálása 


A 3.4. Konstruktorok és destruktorok részben láttuk, hogy az objektumok ál- 
lapotát (vagyis tagváltozóit) az osztály konstruktoraiban lehet inicializálni. 
Példánk, némiképp átalakítva, a következő volt: 





Az inicializálást és az értékadást a Ctt nyelvben élesen meg kell különböz- 
tetni. Mi is a különbség? Az alábbi sorok mindegyike inicializálást, vagyis 
konstruktorhívást jelent. 





Az inicializálás a változók, illetve objektumok létrehozásához kapcsolódik. 
Ezzel ellentétben az alábbiakban az ,—" jel értékadást jelent, azaz egy már 
meglévő változónak, illetve objektumnak adunk új értéket: 





Értékadás esetén az — operátor? és nem a konstruktor hívódik.?! Hogyan 
kapcsolódik ez a gondolatmenet a Point osztály konstruktorához? Annak tör- 
zsében az x — nx; y — ny; utasítások az x és az y tagváltozót már nem iniciali- 
zálják: itt utólagos értékadás történik. Lehetőség van azonban a tagváltozók 
inicializálására is, ennek szintaktikája a következő: 





20 Az operátorokról és túlterhelésükről a 6. fejezetben lesz szó. 
n Saját osztályok esetén a konstruktor és az - operátor egymástól függetlenül megírható, 
vagyis a két esetben más-más kód fut le. 
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A tagváltozókat konstruktorunk úgynevezett inicializálási listájában (const. 
ructor initializer list) tudjuk inicializálni. Az argumentumlista zárójelét köve. 
tően ,:-ot kell írnunk, majd ezt követően felsoroljuk az inicializálni kívánt 
tagváltozókat, zárójelben megadva a kívánt kezdőértéket. A kezdőértékek he. 
lyén felhasználhatjuk a konstruktorparamétereket, de írható ide konstans, 
vagy meghívható egy a tagváltozó típusának megfelelő visszatérési értékkel 
rendelkező globális vagy tagfüggvény is. 

Bár az előző példában inicializálási lista nélkül is konzisztens kezdőálla- 
potba hozhattuk objektumainkat, ez nincs mindig így. Tekintsük meg az 
alábbi példát: 





A Circle osztály két tagvi 


áltozóval rendelkezik. Az osztálynak egy kétparamé- 
terű k. § osztálynak egy kétp. 
jele E EL ÁNBESÁT SE KZEBES Paraméter egy-egy tagváltozó kezdőértéké- 
féket adjuk ezzel sites 4, 1 sorban az r tagváltozónak az nr paraméter ér- 
Folk vágyik ; semmi gond. A Circle osztály center nevű tagváltozója 
egy Point típusú objektumra. A referenciáról tudjuk, 





ba iniciatizátása 
Cirde c1; 


[nr] Ponte: 
Fort come fee[ tk 


7. ábra. Circle típusú objektumok memóriaképe 


Most nézzük meg azt az esetet, amikor a Circle osztály nem referenciaként 
tartalmazza a Point objektumot. Ekkor azt mondjuk, hogy a center egy Point 
típusú beágyazott objektum: 





Ez esetben a Circle objektumok memóriaképe a következő: 


Circle c1; 


HETES EG 
e] ; Point center 


8. ábra. Circle típusú objektumok memóriaképe beágyazás esetén 


Példánkban "72 sorban utólagos értékadás történik (az — operátor hívódik), 
vagyis mire ehhez a sorhoz érünk, a center beágyazott objektum már létrejött, 
mégpedig annak alapértelmezett konstruktorával. Esetünkben ez azért külö- 
nösen kellemetlen, mert a Point osztálynak nincs is alapértelmezett konstruk- 
tora (hiszen írtunk más konstruktort, az alapértelmezettet meg nem írtuk 
meg), így fordítási hibát kapunk. Mi a megoldás? Az, hogy beágyazott objek- 
tumunkra az inicializálási listában meghívjuk a megfelelő (esetünkben a má- 
soló) konstruktort. A megoldás tehát a következő; 




















3. fejezet: Objektumok és osztályok 


3.8. Statikus tagok 


hetőség van olyan speciális, úgynevezett statikus tag. 
oz, és nem az osztály objek. 
ály minden objektumára 
ában is egy helyen 
álhatók, hogy az 


Osztályok esetében le j 
változók definiálására, melyek az adott osztál 
tumaihoz tartoznak. A statikus tagváltozók az osz m 
vonatkozóan közös értéket vesznek fel (ugyanis a memóri 
tárolódnak, de erre még visszatérünk). Só nélkül is has n 
osztálynak egyetlen objektuma lenne. A statikus tagváltozókat os álto- 
zóknak is szokás nevezni. Kiindulásképpen tekintsük az alábbi kódrészletet: 















/7 File: A.h 
class A 


í 
public: 
int x; 
static int sx; 
static int GetsXO; 
h 
// File: A.cpp 
$include cstdio.h: 
finclude "A.h" 


int A:asx.z 2 
int A::GetsSXO // Itt nem kell használni a static kulcsszót. 


return sx; 


üg main(void) 


PrintfCsdin", A::SX); // 1-et ír ki 





"96dtn! , Ar:GetsXO); 


A statikus tagváltozó deklar: 


2 álásához az Áá íció a static2? kulcs- 
szót kell használni. osztálydefinícióban a static? k 








j 


A statikus tagváltozók esetében azonban ez önmagában nem jelent helyfogla- 
lást, a változót az osztálydefiníción kívül definiálni is kell. A fenti kódrészlet- 
ben erre szolgál a következő sor: 


A szintaktika hasonlít a globális változók definíciójához, de itt természetesen 
a hatókör operátorral (::) jelezni kell, melyik osztályhoz tartozik a statikus 
változó. Kezdőértéket nem kötelező adni, bár a kód jobb olvashatóságának ér- 
dekében mindenképpen javasolt. Ha nem adunk kezdőértéket, akkor beépí- 
tett típusok esetében 0 kezdőértéket kap a változó, osztályok esetében pedig 
az alapértelmezett konstruktor hívódik meg. Ezt a definíciós részt mindig for- 
rásfájlba tegyük.23 

A statikus tagváltozókat az osztály tagfüggvényein kívül a hatókör operá- 
torral az osztály nevén keresztül lehet elérni, erre látunk példát a main függ- 
vény első sorában: 


Amikor ez a sor lefut, még egyetlen objektum sem létezik, de a statikus tag- 
változó természeténél fogva már használható. A statikus tagváltozók az ob- 
jektumokon keresztül is elérhetők, de ezt a formát ritkán használjuk: 


Az sz statikus tagváltozó minden objektumra közös, így az A::sx forma sokkal 
kifejezőbb, mint az al.sx. Az A a2; sort követően kialakult memóriakép a kö- 
vetkező: 


A at; 

EZŐEIA] A statikus tag minden 
objektumra közös. 

A a2; 





észlesszei 


9. ábra. Statikus és nem statikus tagváltozók a memóriában 


25 Ha fejlécfájlba tesszük és azt több forrásfájlba include-oljuk, akkor a változó többször de- 
finiált lesz, ami linkelési hibát okoz. 
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s——— — 


ka Objektumok és osztályok 


tumokban csak a nem statikus tagváltozóknak fog. 


Jól KENE áz hasát tagokhoz pedig egy külön memóriarekesz tartozik, 
KZOETEHEN program indulásakor foglalódik hely, és amely a programból való 
am 


; dul fel. ú4 já ; 
e ELEG gváltozók mellett statikus tagfüggvények definiálására is 
ERESTE Ehhez az adott tagfüggvényre vonatkozóan a static kulcsszót 
kell megadni. Ilyen a fenti példában a GetSX tagfüggvény. A statikus tag- 
függvények azáltal nyernek értelmet, hogy objektum nélkül, az osztály nevén 
keresztül is használhatók: 


KETGETREFESKANA  TAETGGESKŐJ TT A] 


A statikus tagfüggvények a statikus tagváltozókon s dolgoznak". Nem statikus 
tagfüggvényből a statikus tagváltozók és tagfüggvények elérhetők. Statikus 
tagfüggvényekből viszont a nem statikus tagváltozók és tagfüggvé- 
nyek nem érhetők el! Az alábbi példa alapján gondoljuk végig, miért nem. 





A main függvényben az A osztály GetX statikus függvényét az A osztály ne: 
vén keresztül hívjuk meg. Ehhez egyetlen objektumot sem hoztunk létre. 
A GetX törzsében az x nem statikus tagváltozó, amely viszont mindenképpen 
egy objektumhoz kötődne. A GetX-re vonatkozóan így fordítási hibát kapunk. 
Továbbgondolva: a GetX törzsében a return x; jelentése return this-2x;. A this 


ks mé ERSZ : is objektumra mutatna, de a statikus függvényeket 
úlga HEG dev használhatjuk (mint a példában is tettük), így nincs 
Tesztelés; kés sz Als is mutathatna, Általánosságában az alábbi követ- 
ALTE 5 ]e: statikus függvények törzsében a this mutató nem 

Gyakorlásképpen írjunk egy olyan osztályt, amely nyilvántartja, hány ob- 


oldás fussszáátég " és ennek lekérdezésére műveletet is biztosít. A meg: 








Az objektumok számának nyilvántartására egy minden objektumra közös sta- 
tikus tagváltozót alkalmazunk, ennek a count nevet adtuk. Ezt az adatelrejtés 
elveit követve privát statikus tagváltozóként definiáltuk. A count változó lekér- 
dezésére a GetCount statikus tagfüggvényt vezettük be. A count változó értékét 
a konstruktorban eggyel növeljük, a destruktorban pedig eggyel csökkentjük, 
így mindig biztosan az aktuálisan létező A osztálybeli objektumok számát tar- 
talmazza. A main függvény az A osztálybeli objektumok számára vonatkozóan 
kettőt ír ki a kimenetre, mert a kiírás előtt két objektumot hoztunk létre: egyet 
lokális változóként, egyet pedig a new operátorral, dinamikusan. 

Összefoglalásképpen elmondhatjuk, hogy statikus tagváltozókat akkor 
célszerű használni, ha az osztály minden objektumára közös változóra van 
szükség. Elvileg globális változó is használható erre a célra, de a statikus vál- 
tozók alkalmazása szebb megoldást eredményez, mert kifejezi, hogy a változó 
az osztályhoz tartozik. Így az esetleges névütközés veszélye is kisebb. Ugyan- 
ezen okokból kifolyólag a statikus tagfüggvényekre is gondolhatunk a globális 
függvények objektumorientált alternatíváiként. 





Útmutató: Azon esetekben, amikor egy funkciót globális függvénnyel valósítanánk meg (mert 
nem köthető egy objektumhoz), törekedjünk statikus tagfüggvények alkalmazására. 














3. fejezet: Objektumok és osztályok 





A statikus tagváltozókkal kapcsolatban van még egy lényeges tudnivaló. A sta. 
tikus tagváltozók mindig az alkalmazás indulásakor, a main függvénybe való 
belépés előtt inicializálódnak a globális változókkal együtt. Ennek megfelelően 
téves az a feltételezés, hogy az induláskor a main függvény első sora az első 
futtatott kód, hiszen statikus és globális objektumaink konstruktorai már ez 
előtt lefutnak. Ezt az alábbi kódrészlet illusztrálja: 


$include cstdio.h: 


int mainO 


printf("Function main has been called.n"); 


class Myclass 


1 
public: 
Myclass(const chart name) 
( 
printf("myclass constructor has been called, name: sin", 
name) ; 
ii 


3 


class Container 

jú 

5 static MyClass staticobject; 
, 


Myclass Container::staticobject("stati cobject"); 
Myclass globalobject("globalobject") ; 
A kód futtatásakor a kimeneten a következő jelenik meg: 


Myclass constructor hás been called i j 

name: staticobject 
MyClass constructor has been called, name: Giobalóbiást 
Function main has been called. 


3.9. Beágyazott definíciók" 


ZART KAGSA té lehetőség van enumeráció-, osztály-, struktúra- és típusdefiní- 
s za ef) osztálydefiníción belüli megadására. Ezeket beágyazott definí- 
HERE eszét 8. kt hl) nevezzük. Mivel haladó technikáról van szó, ameny- 
nyügcdtan Fri galeszjó még csak most ismerkedik a Ct-t nyelvvel, a fejezetet 
BE atciktáts 18 rhatja, és a későbbiekben visszatérhet rá. A beágyazott definí- 
almazását az alábbiakban egy összetettebb példával illusztráljuk. 
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3.9. Beágyazott definíciók" 





$include cstdio.h: 


class IntFifo 


5 E 

private: 
friend class IntFifolterator; 
// Azt IntFiforterator egy beágyazott osztálydefiníció 
class IntFifolterator 


// Referencia az iterált Fifo objektumra. 

IntFifog fifo; 

int currentindex; 

public: 

IntFifolterator(IntFifog fifo): 
fifocfifo), 
currentIndex (0) 

13 


intg GetcurrentO ( return fifo.ppatalcurrentindex]; h 
void MoveNext() ( ricurrentiIndex; ) 


bool IsDoneO; 
3; 
public: 
// A GrowWode egy beágyazott enum definíció 
enum GrowMode ( AutoGrow, FixedSize ); 
// Az IntFiforIterator egy beágyazott típusdefiníció 
typedef IntFifolterator Iterator; 
// Az IntFifolIterator egy beágyazott típusdefiníció 
typedef IntFiforlteratort IteratorPointer; 


Iteratort createlterator() ( return new IntFiforterator("this); 3 


private: 
int" ppata; // Mutató az elemeknek lefoglalt hely elejére 


int size; // A FIFO mérete, maximális elemszám 

int count; // A FIFO-ban aktuálisan levő elemek száma 
int currentPos; // Az első üres hely indexe 

GrowMode growMode; 


public: 
// konstruktor. Paramétérek: 
// size: A FIFO mérete. 
// growMode: A FIFO viselkedését definiálja, ha betelt. 
IntFifoCint size s 100, GrowMode2t growMode z FixedSize): 
pData (NULL); size(size), 
count(0) , currentPos(0) , growMode(growMode) 





nozott típusú változók és függvényparaméterek megadásakor az 





na A Ctt nyelvben a 
enum kulcsszó elhagyható. 
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dalásként a 3.5.2. Dinamikus adattagok támogatása részben ismertetett 


Mel b sét fel. Az IntFifohoz egy olyan egyszerű IntFifoltera- 
unk, mellyel az IntFifo objektumok elemei szekvenciálisan el- 


érhetők. Az IntFifol ka ge 
re, a MoveNext TSÁÉE KIEECTTENI tagfüggvénye az aktuális elem elérésé- 


éz ző elemre lépésre, az IsDo. di ak megállapí- 

tására § , sDone pedig annak meg: 
EGES 8 MÉ KENÉÉB HOTÁR túlléptünk-e az utolsó elemen. Ezek 
tumoknak mindig csak HEVÉBEN találunk példát. Az IntFifolterator objek- 
Ennek következtében a SEjen 0 objektummal együtt van létjogosultságuk. 
adni a cél IntFifo öbjelké ntFifolterator konstruktorában mindig meg kell 
IntFifolterator objektum, Tó; amire az iterátor egy referenciát el is tárol. Az 
egyes IntFifo objek: ok létrehozása nem önmagukban történik, hanem az 
Jektumoktól kérhetők Createlterator tagfüggvényük meghívá- 





— —— 3.9. Beágyazott definíciók" 

A példában az IntFifolterator IsDone tagfüggvénye nem az osztálydefini- 

cióban definiált. Ez esetben a definíció megadásakor a tagfüggvény teljes , el- 
érési útvonalát" meg kell adni a hatókör operátor (::) felhasználásával: 





Az IntFifo osztályban a GrowMode beágyazott enumeráció definíció az 
IntFifo objektumok viselkedését szabályozza abban az esetben, ha a FIFO be- 
telt (AutoGrow: automatikusan nő, FixedSize: hibával tér vissza). A műkö- 
dés az IntFifo konstruktor második paraméterében a megfelelő enumerált ér- 
ték megadásával szabályozható. 

A IntFifo két beágyazott típusdefiníciót is tartalmaz: 





Mindkettő az IntFifolterator alapján hoz létre egy új típust. 

A beágyazott definíciók csak a tartalmazó osztályból érhetők el közvetle- 
nül. Globális függvényekből és más osztályok tagfüggvényeiből a beágyazott 
definíciók csak a minősített nevükkel érhetők el. A minősített név a ható- 
kör operátorral (::) adható meg a következő formában: tartalmazó osztály ne- 
ve::beágyazott definíció neve. Erre vonatkozóan a main függvényben látunk 
példákat. Az első sorban a GrowMode beágyazott enumeráció AutoGrow érté- 
ke az IntFifo::AutoGrow kifejezéssel érhető el. A beágyazott IteratorPointer 
típusdefiníció elérése hasonló módon történik néhány sorral lejjebb: 





A beágyazás alkalmazásának előnye itt látható igazán. A kód szemlélete- 
sen kifejezi, hogy az adott definíció szorosan a tartalmazó osztályhoz 
tartozik, csak annak kontextusában van értelme. Globális megvalósítás 
esetén a névütközés esélye is nagyobb lenne. 

A példában a beágyazott definíciókat nem véletlenül tettük a tartalmazó 
IntFifo osztály elejére. Ezeket definíciókat ugyanis a forrásfájlban a tartal- 
mazó osztály csak a definíciót követően használhatja. Beágyazott definíciók 
tetszőleges mélységben alkalmazhatók, így a példa kapcsán lehetőség volna 
további definíciók beágyazására az IntFifolterator osztályba. 





26 A megfelelő viselkedés implementációja számunkra nem érdekes, így a kódrészlet nem 
tér ki rá. új 
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íciókra vonatkozóan a megszokott láthatósági szabá. 

A EZ SESERE CÖkázkáételeléen a privát szakaszba ágyazott defini. 
Che öslén tartalmazó osztály tagfüggvényei által elérhetők, a publi- 
mának pedig a külvilág (például main függvény) számára is hozzáfér- 
or osztály privát, a többi beágyazott defi. 


, Példánkban az IntFifolterat ; y 
Al ÖnöÉGE A megoldás előnye, hogy az IntFifolterator csak közvetve (az 
Iterator és IteratorPointer típusdefiníción keresztül) használható, így szaba. 


don megváltoztatható. Szintén a hozzáférésre vonatkozó szabály, hogy a be- 
ágyazott osztály nem ad speciális jogokat a tartalmazó osztálynak, és 
a tartalmazó osztály sem biztosít speciális jogokat a beágyazott osz- 
tály számára. Az IntFifolterator osztály azáltal fér hozzá az IntFifo védett 
tagjaihoz, hogy az IntFifo az IntFifolterator osztályt friendnek deklarálja. 

A beágyazott definíciók alkalmazását nem szabad túlzásba vinni. A Szab- 
ványos C4-- Könyvtár esetében ugyanakkor széles körben találkozhatunk be- 
ágyazott típusdefiníciók alkalmazásával. Sőt, az egyes tároló osztályok iterá- 
torainak megvalósítása is az itt bemutatotthoz hasonlóan, beágyazott módon 
történik. A Szabványos C-t Könyvtár természetesen az itt ismertetettnél sok- 
kal kifinomultabb megoldásokat alkalmaz, az egész iterátorkoncepció — a tároló 
osztályok széles körére megvalósítva — ezáltal nyer igazi létjogosultságot. A té- 
makörbe részletesebb betekintést a 12.1. Alapkoncepciók fejezet nyújt. 


5 Bár a Cst szabvá 2 
Pi , Szabvány szerint á A azált 
védett tagjaihoz, a fordítók ZU P ÁSTA osztály nem férhet hozzá a tartalmazó osztály 


A szabvány ez irányú HSZ né mosgzsrügy ágat alkalmazása nélkül is megengedi 
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NEGYEDIK FEJEZET 


Konstansok és inline 
függvények 


4.1. A const használata 


A C44 nyelvben a const kulcsszónak számos felhasználási területe van. Al- 
kalmazható konstans változók és függvényparaméterek definiálására, vala- 
mint annak jelzésére, hogy egy osztály tagfüggvénye nem változtatja meg az 
osztály objektumainak állapotát. A const alkalmazásának elsődleges célja a 
hibalehetőségek csökkentése. Amennyiben egy constnak definiált változó ér- 
tékét figyelmetlenségből megpróbáljuk megváltoztatni, a fordító figyelmeztet, 
így a hibát a lehető legkorábban sikerül megfogni. Bár sokan gondolják, hogy 
a const alkalmazása nélkül is megfelelő programokat tudnak készíteni, előbb- 
utóbb a legtöbb fejlesztő (szerencsére) rákényszerül a const használatának 
mélyebb megismerésére azáltal, hogy az elterjedtebb osztálykönyvtárak (pél- 
dául a Szabványos Ct- Könyvtár) is alkalmazzák. 


4.1.1. Konstans , változók" 


A C nyelvben konstansok helyett sokszor makrót használunk, amelyre a 
Hdefine alkalmazható, az alábbiaknak megfelelően: 


$define MAX ELEMSZAM 10 
char buff[[MAX-CELEMSZAM] ; 





Az elemszámot azért definiáltuk konstansként, hogy értékét egy helyen (a 
MAX. ELEMSZAM definíciónál) lehessen megváltoztatni, akárhányszor hasz- 
náljuk is fel. A $define alapú megoldásnak azonban több kellemetlen követ- 
kezménye van, ugyanis kifejtését a preprocesszor végzi el, amely jó közelítés- 
sel egy egyszerű szövegszerű behelyettesítést jelent. A fdefine MAX ELEM- 
SZAM 10 sor végére nem szabad pontosvesszőt tenni, mert ekkor valamennyi 
felhasználási helyen a 10 helyett 10; kerül behelyettesítésre, ami a fenti pél- 
dában fordítási hibát okoz. Erről könnyű megfeledkezni. A másik, nagyobb 
probléma, hogy a ttdefine alkalmazásával nem lehet megadni a konstans tí- 
pusát, ami a MAX ELEMSZAM-ra vonatkozóan az int típus lenne. Ez tovább 
korlátozza a fordításkori hibaellenőrzést. A C-t nyelvben ennek következté- 
ben konstansok definiálására a const kulcsszót célszerű használni. Ez egy tí- 














4.1. A const használata 





4.1.3. Konstans függvényparaméterek 


7 z k A const függvényparaméterek esetében is alkalmazható. Sőt, talán ez a leg- 
definiálásakor jelezzük a gyakoribb felhasználási területe. A konstans függvényparaméterek paramé- 
terátadáskor inicializálódnak, a függvény törzsében azonban nem megváltoz- 


4. fejezet: Konstansok és inline függvények 


változó, illetve objektum j 
Kelt ea egy értéke nem változtatható meg. A const egyaránt 


alkalmazható globális, lokális és tagváltozók, valamint EZ MÁNOR SE) tathatók. Vizsgáljuk meg ennek lehetőségeit és célszerűségét közelebbről. 

esetében. A globális, lokális és tagváltozók esetében EGétA MEGÉRT, Guns többi Közvetlen, érték szerinti paraméterátadás esetén a const alkalmazása 
Következzen egy példa konstans globális változó definiálására, mig kevésbé célszerű, hiszen az eredeti változóról a paraméterátadás során máso- 
esetet a későbbiekben mutatjuk be. lat készül, a függvény törzsében csak ezt a másolatot lehet megváltoztatni. 


EREZEROTNEEKBE TŐ 77" ESZOSZBRA Mindenesetre a fordító ez esetben is megengedi az alkalmazását: 


i áli ó úgy használhatók, 
A konstans globális, lokális és tagváltozók pontosan ugyanúgy ihat 
Aj közönséges változók. Mindössze az a különbség, hogy ha megpróbáljuk 
megváltoztatni az értéküket (jellemzően figyelmetlenségből), akkor fordítási 
hibát kapunk. 





4.1.2. Konstans pointerek 


A referenciatípus alkalmazásáról szóló fejezetben említettük, hogy a nagyobb 


Pointerek esetében a constnak két felhasználása is lehet. Egyrészt jelezhetjük méretű objektumokat, struktúrákat referenciaként célszerű függvényparamé- 
vele, hogy a mutatott érték, másrészt, hogy maga a mutató megváltozhatat- terben átadni, mivel így elkerülhető, hogy a paraméterátadás során másolat 
lan. Az alábbiakban a különböző eseteket vizsgáljuk meg. § készüljön róla. Ez nagyban hozzájárulhat az alkalmazás hatékonyabb műkö- 

Amennyiben a constot a típus elé írjuk, a mutatott érték lesz megváltoz- déséhez. A megoldásnak azonban van egy komoly hátulütője: a függvény tör- 
hatatlan: zsében a referencián keresztül az eredeti objektum vagy struktúra figyelmet- 


lenségből megváltoztatható. Ugyanez a helyzet, ha nem referenciát, hanem 
pointert alkalmazunk. Természetesen ez csak akkor tekinthető hátránynak, 
ha nem célunk az eredeti objektum megváltoztatása. Szerencsére a const al- 
kalmazásával az ilyen jellegű hibák fordítási időben kiszűrhetők. A megoldás 
kézenfekvő: az adott paramétert konstans referenciának (pointer eseté- 
A példában a p típusa pointer karakterre, ami konstans. Ez esetben a p által ben konstans pointernek) kell definiálni: 
mutatott tartalmat csak olvasni lehet, megváltoztatni nem. Ugyanezt a visel- 
kedést kapjuk, ha a constot a típusnév és a " közé írjuk (char const? p — t,). 
Amennyiben a constot a változó neve elé írjuk, a mutató lesz megváltoz- 
hatatlan: 








a Nemcsak függvényparaméter, hanem a függvények visszatérési értéke is le- 
A példában a p típusa konstans pointer karakterre. Természetesen lehetőség het konstans, erre mutat példát az alábbi kódrészlet: 
van a két eset kombinálására: 





A példában a p típusa konstans pointer konstans karakterre. 
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A példában a GetName tagfüggvény konstans pointerrel tér vissza a name 
tagváltozóra. Célunk a const alkalmazásával az volt, hogy a GetName által 
visszaadott pointeren keresztül ne lehessen megváltoztatni a name által mu- 
tatott memóriaterületet, vagyis a személy nevét. 

A const-tal kapcsolatban még megjegyezzük, hogy olyan módosítószó, 
amely új típust hoz létre abban az értelemben, hogy a függvények túlterhelé- 
se szempontjából is megkülönböztető erejűnek számít (a függvények túlterhe- 
léséről a 2.2. Függvénynevek túlterhelése fejezetben olvashattunk). 


4.1.4. Konstans tagváltozók 


Osztályok tagváltozói is lehetnek konstansok. Ezeket az osztály konstrukto- 
rainak inicializálási listájában kell inicializálni. Tegyük fel, hogy az előző fe- 
jezetben bevezetett Person osztályunk úgy reprezentál személyeket, hogy a 
születési év nem változtatható meg, míg a név igen. Ekkor a születési évet 
célszerű konstansnak definiálni: 





Bár ez a legegyszerűbb megoldás a karakterek másolására, a gyakorlatban ne alkalmaz- 
zuk, mert ún. buffertúlcsordulási (buffer overrun) problémát okozhat. Ez esetünkben ak- 
kar fordul elő, ha a forrássztring 255-nél több karaktert tartalmaz. Az strcpy függvény- 


nek ugyanis nincs módja ellenőrizni célbufferünk méretét, 


, így .túlír" az ál: lefoglalt 
érvényes memóriaterületen. Megoldás lehet, ha a ga SZ SASoSzAA ÉR 


másolás előtt az strlen függvénnyel el- 
ni it, vagy ha az strepy olyan változatát 
használjuk (például Visual O4-t esetén az strepy. s, de ez fordítófüggő), amelynél megadható 
válnogzizánygkem . A Jegkényelmesebb megoldást pedig akkor kapjuk, ha a sztringek keze- 

rea terminált char mutatók helyett a Szabványos Cs- Könyvtár dinamikusan 
nyújtózkodó string osztályát használjuk (ásd 12.5. Szövegkezelés fejezet) 








pi 


Egy másik példával azt szemléltetjük, hogy statikus konstans tagváltozók de- 
finiálására is van mód: ? 





Mint a példában látható, statikus konstans egész típusú tagváltozók akár 
inline" módon (a tagváltozó definiálásának helyén) is inicializálhatók. Más 
típusok esetében a konstans statikus tagváltozókat a megszokott módon, az 
osztálydefiníción kívül kell inicializálni. 


4.1.5. Konstans tagfüggvények 


A const tagfüggvények esetében is használható, a tagfüggvények fejlécének 
végére írva. Az alábbi kódrészletben az előző fejezetben bevezetett Person osz- 
tályt írtuk át úgy, hogy a GetName tagfüggvénye konstans legyen. 
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A const jelentése ez esetben az, hogy az adott tagfüggvény az objektum álla- 
potát, vagyis annak tagváltozóit nem változtatja meg. Amennyiben ezt mégis 
megkíséreljük (például a GetName törzsébe a name[0] - "B; írásával), fordí- 
tási hibát kapunk. Azon tagfüggvényeket, amelyeknél előre tudjuk, hogy nem 
változtatják meg az objektum állapotát, célszerű constnak definiálni, így ha 
svéletlenül", a fejlesztő hibájából mégis megváltoztatná, már fordításkor kide- 
rül. A konstans tagfüggvények esetében tulajdonképpen a this mutató defini- 
ált konstans objektumra mutató pointerként. 

Egy konstans tagfüggvényből az osztálynak csak konstans tagfüggvénye 
hívható. Máskülönben előfordulhatna, hogy egy konstans tagfüggvény egy 
nem konstans tagfüggvény meghívásával közvetve megváltoztatja az objek- 
tum állapotát. 

: Konstans objektumra — teljesen logikus módon — csak konstans tagfügg- 
vények hívhatók. Person osztályunk felhasználásával tekintsük meg az alábbi 
függvényt: 





Ez az ellenőrzés is azt a célt szolgálja, ho; j 

8 , hogy egy konstans objektum állapotát 
nem konstans tagfüggvény meghívásával ne lehessen megváltoztatni. erők 
szetesen a konstans tagfüggvények mind konstans, mind nem konstans ob- 


jektumokra hívhatók. Gondoljuk végi. a 
származhat, A tanulság a jssndbesi £, hogy ebből semmilyen probléma nem 





4.1. A const használata 





Az osztályok tagfüggvényei és operátorai tisztán a konstans mivoltukban való 
különbözőség esetén is túlterhelhetők.? Ezt a gyakorlatban sokszor ki is 
használjuk: 


class String 





! [ é 
. charg operator[] (Cin a / 
h 1 ; : 5y 
int main(void) i 
1 
String s("abc"); 
const String cs("abc"); . 
printf("Xd", s[01); // A 0. indexű elem olvasása. 
printfCxd", cs(01); // A 0. indexű elem olvasása. 
s[0] -— "x"; // A 0. indexű elem írása. 
cs[0] - "x!; // A 0. indexű elem írása, fordítási hiba. 
h 


A String egy sztring objektumokat reprezentálni képes osztály. A tárolni kí- 
vánt karaktereket a konstruktorban adhatjuk meg, amit bemásolunk a new- 
val lefoglalt területre. A String osztályban a tömbindex operátornak (opera- 
tor[]) két változatát is megírtuk. A konstans változat hívódik a konstans, a 
nem konstans változat a nem konstans String objektumok esetében. A kü- 
lönbség mindössze az, hogy a nem konstans verzió referenciával tér vissza az 
adott karakterre. A main függvényben az s objektum nem konstans, erre vo- 
natkozóan a nem konstans, referenciával visszatérő operator[] hívódik meg 
(2). Mivel ez a verzió referenciával tér vissza, a visszaadott elem megváltoz- 
tatható. Ezzel szemben a cs objektum konstans, erre vonatkozóan a konstans, 
charral visszatérő operator[] változat hívódik meg ("1). Az operator[] ez eset- 
ben a String objektum által tárolt karakter másolatával tér vissza, ami nem 
számít balértéknek, így ennek megváltoztatásának kísérlete a cs[0] 7 "x sor- 
ban fordítási hibát okoz. A gyakorlatban a megoldás pont a kívánt hatást 
eredményezi: csak a nem konstans sztring objektumok karakterei változtatha- 
tók meg. Azáltal, hogy mindkét operator[]-t megírtunk, más-más viselkedést 
biztosíthattunk a konstans és a nem konstans String objektumok esetében. 








24 Az operátorok túlterheléséről a 6. Operátorok és túlterhelésük fejezetben lesz szó. 
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4.1.6. Mutable tagváltozók 


Ritkán, de előfordulhat, hogy egy konstans tagfüggvényből engedélyezni kí. 
vánjuk egy adott tagváltozó megváltozását. Ez esetben az adott tagváltozót 
mutable-nek kell definiálni: 





következő sor nem hibás, 777 





Csak nem konstans és nem statikus tagváltozókat lehet mutable-nek definiálni. 
A mutable logikája az, hogy az objektum állapotát szemantikailag akkor is 
változatlannak tekintjük, ha a mutable tagváltozó megváltozik. 


4.1.7. Const — nem const konverziók 


A szabály a következő: nem constról constra van automatikus konver- 
zió, fordítva viszont nincs. Ez megfelel az elvárt működésnek. Ha egy nem 
konstans változót konstansként kívánunk kezelni, abból baj nem lehet (legfel- 
jebb nem tudjuk az értékét megváltoztatni). Viszont a const — nem const 
konverzió veszélyes, mert ezt követően lehetőség van az adott változó, illetve 
objektum állapotának megváltoztatására. Márpedig bizonyára azért definiál- 
tuk vagy definiálta valaki az adott változót konstansnak, hogy ez ne legyen 
lehetséges. A változtatás ez esetben nyilvánvalóan ellentmond korábbi szán- 
dékunknak, illetve valaki más szándékának. 

Az automatikus konverzióra vonatkozó szabály következményeit alapo- 
san megvizsgáljuk. Nézzük meg az alábbi függvényeket: 








44. Aconst használata 





A ProcessPerson első sorában ("1) nincs konverzió: a p változó típusa Persondt, 
a PrintPerson paramétere Person$-. A következő sorban ("2) sincs konverzió, 
a cp változó és a PrintPersonConst függvény paramétere is konstans. Az ezt 
követő sorban ("3) a nem const 5. const automatikus konverzióra látunk pél- 
dát: a p nem konstans, de a PrintStringConst konstans referenciaként veszi 
át. Ennek következtében a PrintPersonConst az objektumot konstansként ke- 
zeli. A ProcessPerson függvény "4 sora viszont fordítási hibát eredményez: a 
cp objektum konstans, ezt nem konstans referenciaként venné át a Print- 
Person. A fordító ezt nem engedi, hiszen a PrintPerson függvénynek , jogában 
állna" megváltoztatni az objektumot. 





Útmutató: Egy függvény megírásakor a szemantikailag is konstans paramétereket azért is 
érdemes constnak definiálni, mert a függvény szélesebb körben lesz felhasználható: csak ez 
esetben adhatók át mind konstans, mind nem konstans változók, illetve objektumok paramé- 
terként. 





A PrintPerson( cp ); esetében is az a probléma, hogy a PrintPerson függvény tel- 
jesen indokolatlanul nem konstans referenciaként veszi át a Person objektumot. 

Nézzük meg most a ProcessPerson függvény "5 sorát: PrintPerson( (Per- 
son€Jep );. Itt egy explicit const - nem const konverzióról van szó. Ez legális, 
de alkalmazása csak a legritkább esetben indokolt. Ha ilyet teszünk, mindig 
gondoljunk bele: nem véletlenült állt valakinek szándékában az adott válto- 
zót, illetve objektumot konstansnak definiálni! 

Ha a const 5 nem const konverzióra egy adott helyzetben mindenképpen 
szükség van és meggyőződtünk róla, hogy ez nem okoz problémát, akkor a 
konverzióra a (Persong-)cp helyett célszerű a biztonságosabb const cast operá- 
tort használni. A const. castról és az egyéb konverziós operátorokról bővebben 
a 8.3. A Ct- típuskonuverziós operátorai fejezetben olvashatunk. 
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4. fejezet: Konstansok és inline függvények 
ez eze ez ZRKZZKTZKKKZEKKKKERttkltéevwö é—. 


4.2. Inline függvények 


A forráskód könnyebb karbantarthatósága és olvashatósága érdekében gyak. 
ran célszerű a rövid kódrészeket is külön függvénybe tenni. Például ilyen két 
változó közül a nagyobb értékű kiválasztása. Írjunk erre vonatkozóan egy 


max nevű függvényt: 





A max hívásának helyébe a ab ? a:b kifejezést is írhatnánk, de a max függ- 
vény használatával kifejezőbb a kód. Ráadásul, ha módosítani kell a kódot, 
csak egy helyen kell megtenni, akárhány helyen is használjuk. Rövid művele- 
tek esetében azonban a függvényhívás viszonylag költségesnek tekinthető, 
egy függvényhívás ugyanis — némiképp leegyszerűsítve — a következő lépé- 
sekkel jár együtt:30 


1. paraméterek elhelyezése a veremben; 

2. visszatérési cím elhelyezése a veremben és ugrás a függvény címére; 
3. függvénytörzs végrehajtása; 
4. 


új visszatérési érték elhelyezése a hívó számára (memóriában vagy Te- 
giszterben); 


gi 


visszatérés a függvényből a hívás helyére; 
6. a verem takarítása (paraméterek és visszatérési érték). 


A helyfoglalás és felszabadítás a legtöbb ű iszter- 
li platformon egyszerű veremregiszter: 
növelést, illetve -csökkentést jelent, így nagyon gyors műveletnek tekinthető. 


Ennek ellenére, ha a Töése ef 83 ő 
Koo zesb utá ú 1 nagyon rövid, akkor a függvénytörzs 
MS TES ideje (4. lépés) jóval rövidebb lehet, mint a többi lépésé. Így a 
függvényhívás ez esetben pazarlónak tekinthető. 
EZÉ szt ő SEN EVŐ 
7 A megadott sorrend a normál C függvényhívási konvenció esetén érvényes. 





4.2. Inline függvények 
SS S SS ed 9. Inine függvények 


A problémára a C nyelvben a makrók jelentenek megoldást. Bár makrók 
a Ctt nyelv esetében is alkalmazhatók, célszerű kerülni őket. A makrók 
használatával kapcsolatban a legtöbb probléma abból származik, hogy a 
makrókat a preprocesszor fejti ki, és jó közelítéssel egyszerű szövegszerű be- 
helyettesítést jelent a hívás helyén. A szövegszerű behelyettesítés egyik kel- 
lemetlen következménye, hogy ha a makrót harminc helyen hívjuk, és hiba 
van benne, akkor a fordító harminc helyen jelez hibát (normál függvénynél ez 
esetben csak egy hibát kapunk). Ennél nagyobb baj azonban, hogy a makrók 
alkalmazása számos, rendkívül nehezen észrevehető hibalehetőséget rejt ma- 
gában. A következő példával egy ilyen esetet világítunk meg: 





A main függvény első sorában az x változót 1-re inicializáljuk. A második sor- 
ban a MAX makróparaméterben az x--t kifejezéssel ezt eggyel növeljük, en- 
nek megfelelően az utolsó sorban az x értékének 2-nek kellene lennie. az 
utolsó sorban az x értéke 3. Ennek okára akkor jövünk rá, ha a MAX makró- 
hívást a szövegszerű behelyettesítésnek megfelelően kifejtjük: 


Jól látszik, hogy az x-tt kifejezés kétszer is kiértékelődik, mert x-t-- nagyobb, 
mint y. Így az x értéke kettővel nő. 

A Cs nyelvben makrók helyett inline függvényeket?! célszerű hasz- 
nálni. Az inline függvények esetében a fordító a hívás helyére behelyettesíti a 
függvény törzsét, így elkerülhetők a függvényhívás járulékos lépései. Ugyan- 
akkor minden más tekintetben a normál függvényekkel azonos módon visel- 
kednek, ennélfogva nem jelentkeznek a makrók alkalmazásánál ismertetett 
problémák. Ez azáltal válik lehetségessé, hogy az inline függvényeket a fordí- 
tó, és nem a preprocesszor dolgozza fel. 

Az inline függvények definiálásának és hívásának szintaktikája meg- 
egyezik a normál függvényekével. Az egyetlen különbség, hogy a függvényde- 
finícióban az inline kulcsszót kell alkalmazni: 


MEZ s (CXII REORG 








"1 Bár az inline globális függvények használatát a legfrissebb C szabvány is támogatja, 90- 
kan csak a Ct4 nyelv kapcsán ismerkednek meg alkalmazásukkal, így ezt a témakört is 
részletesen tárgyaljuk. 
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4. fejezet: Konstansok és inline függvények 





Az inline függvények deklarációjában nem szükséges — és nem is szokás -— 


használni az inline kulcsszót. 
Osztályok tagfüggvényei is inline-ná tehetők, nézzünk egy erre vonatkozó 


példát: 





A példában a Fifo osztály Count tagfüggvényét implicit módon inline-nak defini- 
áltuk azáltal, hogy törzsét az osztálydefiníciós részben adtuk meg. Az IsEmpty 
tagfüggvény szintén inline lesz, mert az inline kulcsszót a tagfüggvény-defini- 
ciónál explicit megadtuk. Az inline kulcsszó a tagfüggvény-deklarációnál is 
megadható, ez nem jelent különbséget. 

§ Az inline globális és tagfüggvények definícióját, amennyiben az adott 
függvényt más forrásfájlból is fel kívánjuk használni, (a nem inline függvé- 
nyekkel ellentétben32) fejlécfájlban kell megadni! Ha a normál függvényekre 
vonatkozó ajánlást követve a fejlécfájlba csak a függvény vagy tagfüggvény 
deklarációját tennénk, akkor a hívás helyére a fordító nem tudná beilleszteni 
a függvény törzsét. Ne feledjük, hogy a fordító a forrásfájlokat egyesével dol- 
gozza fel, a fordítónak egy forrásfájl fordításakor csak az adott forrásfájlra és 
az ítinclude direktívával beépített fejlécfájlokra van , rálátása". Egy ilyen, két 
forrás- és egy fejlécfájlból álló konfigurációt illusztrál a következő kódrészlet: 


ee szet eetegs FÉRÉNSEÉL 4 
" Azajánlott kódszervezésről bővebb leírás 3.3. Adatrejtés fejezetben található. 
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A példában a main függvényben a max hívásakor a fordító nem tudja beillesz- 
teni a függvény törzsét. Pontosabban a fordító normál függvényhívásként le- 
fordítja ugyan, de a linker nem tudja feloldani a hivatkozást, így hibát jelez.38 
A megoldás egyszerű: a teljes max definíciót tegyük be a utils.h fejlécfájlba: 





Előfordulhat ugyan, hogy a fejlécfájl több forrásfájlba való beépítésével (include 
direktíva) az inline függvények, illetve tagfüggvények többszörösen lesznek defi- 
niálva, ez azonban a normál függvényekkel ellentétben nem okoz linkelési hibát. 
Az inline függvényekkel kapcsolatban — legyenek globális vagy tagfüggvé- 
nyek — fontos tudni, hogy az inline alkalmazásával csak egy kérést fogalmaztunk 
meg a fordító számára. A fordító minden esetben egyedileg dönt arról, hogy a 
függvényt inline módon valósítja-e meg (vagyis behelyettesíti-e a törzsét a hívás 
helyére). A döntésben szerepet játszik a függvény mérete, de a függvény inline-ná 
tételének vannak eleve kizáró okai is. Többek között ilyenek a következők: 


s  Felhasználjuk a függvény címét, például függvénypointerek alkalma- 
zásával (ha a függvény inline lenne, a függvénynek nem lenne címe). 


e — Rekurzió alkalmazása: az inline megvalósításnak ez esetben is elvi 
akadálya van. 





55 Akkor is ugyanez történik, ha a max függvény deklarációjában is használjuk az inline 
kulcsszót. 

34 Bizonyos fordítók a ttpragma inline recursion on direktívával adott mélységig rekurzió 
esetén is támogatják a függvények inline kifejtését. , 
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4. fejezet: Konstansok és inline függvények 


Kerüljük az inline függvények túlzott használatát. A hosszabb függvényeket 
inline-nak definiálva a hosszabb függvénytörzs minden hívás helyére behe. 
lyettesítődik, ami a kód méretének jelentős növekedésével, végső soron lassu- 
lásával? járhat. 





Útmutató: Az egy-két sorból álló függvényeket célszerű inline-nak definiálni, amikor is a 

: függvénytörzs végrehajtási ideje összemérhető a függvényhívás járulékos lépéseinek idejével. 
Tipikusan ilyenek a nagyon egyszerű számításokat végző függvények, mint például a max, va- 
lamint osztályok esetében a privát tagváltozók lekérdezésére szolgáló metódusok. 





a A lassulást nagyobb méretű kód esetében jellemzően a rosszabb processzorcache találati 





ÖTÖDIK FEJEZET 


A C-t I/O alapjai 


A C nyelv tanulásának legelső fázisában nem egyszerű a printf és a scanf 
függvény formátumsztringjeinek elsajátítása. Néhány ritkán használt típus 
kiírása esetén gyakori probléma, hogy a hibakeresőben jó az érték, mégsem 
az jelenik meg a képernyőn: ilyenkor legtöbbször a formátumsztring a hibás. 
Ebben a fejezetben megnézzük, milyen alternatívát kínál a C-H4 [/0O, részle- 
tezzük annak alapjait: a szabványos leírók kezelését, a formázás lehetőségeit 
és az állománykezelés alapjait. 


5.1. A szabványos adatfolyamok 


A C nyelvben három előre létrehozott és megnyitott állomány leírója áll a 
program rendelkezésére rögtön indulás után: az stdin (szabványos bemenet), 
stdout (szabványos kimenet), illetve az stderr (szabványos hibakimenet). Ezek 
mindegyike FILE" típusú magas szintű állományleíró, az stdin csak olvasha- 
tó, a másik kettő csak írható. C4--ban a leírók helyett objektumok állnak 
rendelkezésünkre. A C-t-- adatfolyamokban (stream) gondolkodik, amelyek 
tulajdonképpen bájtok sorozatát jelentik. Az adatfolyam típusától függően az 
istream típusú objektumok csak olvasható, bemeneti adatfolyamokat (input 
stream) takarnak, míg az osíream osztály példányai csak írható, kimeneti 
adatfolyamonként (output stream) használhatók. 

Ezek az adatfolyamok a cS, illetve a 22 operátorokat használják kiírásra 
és beolvasásra. Az alábbi táblázat összefoglalja a szabványos leírókat: 














stdin cin istream billentyűzet 
stdout cout ostream képernyő 
stderr cerr ostream képernyő 
€ clog ostream képernyő 


ÓÓ; 


Az első három objektumra példaként bekérünk egy egész számot, majd kiírjuk: 














5. fejezet: A Cr 1/0 alapjai 








A C--- [/0 használatához be kell építenünk az iostream állományt. A második 
sor a szabványos névtérhez enged hozzáférést az std:: előtag használata nél- 
kül, a névtereket a 9. Névterek fejezet ismerteti részletesen. Ha elhagyjuk ezt 
a sort, akkor például std::coutot kellene írnunk. 

Érdemes megfigyelni, hogy a , nyilak" mindig az adatáramlás irányába 
mutatnak: a cout felé, amikor kiíratunk valamit, illetve a változó felé, amikor 
beolvasunk valamit. A main függvény második sorában egy speciális , jelet" 
küldünk az adatfolyamba: az end! a soremelést jelenti. Gyakorlatilag azonos a 


MALKÉGVEÉGGÜLINA "gl nel AKAR ST) z 


sor hatásával. Hogy ne kelljen mindig kiírni a coutot, a kiírás első és második 
sorát akár egy sorba is írhattuk volna. 


5 7egut" eg "Enter an integeks! 44 enddg a et seta 


A jelentése ugyanaz, mintha külön sorban szerepelne. A cc operátort ismételve 
folytathatjuk a sort. Jól látható, hogy az alaptípusokat automatikusan felismeri 
a cc operátor, nem kell bajlódnunk a típust leíró formátumsztringekkel. 

- Ezek után beolvassuk az egész számot. Ennél a műveletnél a cin az alap- 
értelmezett beállítás szerint elhagyja a szóköz jellegű (whitespace) karaktere- 
ket (szóköz Nt Nn, M, 1). A művelet sikerességét egyszerűen a cin ellenőrzé- 
sével végezhetjük. Ha a beolvasás helyes volt, akkor kiírjuk a számot, ellen- 
kező esetben nem. 

A cin működése nagyban hasonlít scanf nevű elődjére. Amikor egy adott tí- 
Pust - jelen esetben egy egész számot — be kell olvasnia, addig halad, amíg az 
egész számra jellemző karaktereket kap, vagy új sor, illetve állomány vége ka- 
rakter nem érkezik. Ha például a 12.3 kifejezést írjuk be, akkor a pontig olvas, 
az egész változó értéke 12 lesz, a többi karaktert nem olvassa be. Így egy soron 
következő cin beolvasás a tizedesponttól folytatja a beolvasást. Nézzük meg az 
alábbi programrészletet, amely egy egészt és egy tizedes törtet olvas be: 
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Fontos, hogy a cin állapotát beolvasás után mindig ellenőrizni kell. Ugyan- 
úgy, mint a C nyelvben, a beolvasást végző függvények után, az adatfeldolgo- 
zást megelőzően kell vizsgálni, hogy a beolvasás elérte-e az állomány végét, 
vagy egyéb hiba lépett-e fel. 

Ha a fenti programot futtatva az egész szám helyett 12.3-at adunk meg, 
akkor az alábbi eredményt kapjuk: 





Mivel az első beolvasással csak a 12-t olvastuk be, a pont után visszatért a 
beolvasás. A második beolvasás a .3-at olvasta be, amely érvényes tizedes 
tört, értéke 0.3, majd a sor vége karakterre visszatért. Vagyis a program nem 
állt meg a második beolvasó utasításnál. C nyelven ezt az 





függvényhívással akadályoztuk meg. C---ban ilyenkor meg kell mondanunk 
az adatfolyam-objektumnak, hogy a sor vége karakterig hagyja figyelmen kí- 
vül a beolvasott karaktereket: 





Az ignore függvény első paramétere egy egész számot vár, amely meghatároz- 
za, hogy maximálisan hány karaktert hagyjon figyelmen kívül. A második pa- 
raméterként egy karaktert kell megadnunk. Ha az ignore függvény talált ilyen 
karaktert, akkor azt még figyelmen kívül hagyja, de az utána következő karak- 
tert már megőrzi. A limits-ben definiált numeric. limitssstreamsizez::maxO fenti 
specializációjat6 megadja a maximális adatfolyam-méretet. Az alábbi prog- 
rammal megelőzhetjük az egyes beolvasások egymásra futását. 


36 A sablonokat 11. Ct4 sablonok fejezet tárgyalja. 














5. fejezet: A Css 1/0 alapjai 





Mivel a rendszerhívások költsége igen nagy, az adatfolyamokat egy bufferrel 
látják el, amelyeket az adatfolyambuffer osztályok példányai valósítanak 
meg. Az adatfolyam-bufferek összegyűjtik a karaktersorozatokat, és több cout 
kiírást egy rendszerhívással írnak ki a képernyőre. Az endl, illetve egy követ- 
kező cin beolvasás automatikusan kiírja a couthoz tartozó buffereket. Ha sze- 
retnénk kiüríteni a buffert, akkor a 


vagy a 


megoldásokat alkalmazhatjuk. Ha viszont éppen fogytán van a memóriánk, 
és ezt közölni szeretnénk a felhasználóval, nem hasznos, hogy a kimeneti 
adatfolyam bufferelt. Ezért a cerr objektum alapértelmezésben nem bufferelt. 
A clog nagyon hasonlít a cerr objektumra: a clog objektum a cerr bufferelt vál- 
tozata. A C nyelvben ennek az objektumnak nincs megfelelője. A neve azt su- 
gallja, hogy inkább hibák naplózására szolgál, mint azonnali megjelenítésükre. 

A hibakezelésnél egyszerűen megvizsgáltuk az adott adatfolyamot egy if 
szerkezetben. Kihasználva, hogy az adatfolyamok objektumok, és állapottal 
rendelkeznek, az esetleges hibákat az adatfolyam állapotából tudhatjuk meg. 
Az adatfolyam állapotát egy iostate típusú tagváltozó jelzi, amelynek állapo- 
tát az alábbi konstansokkal lehet beállítani: 





5.1. A szabványos adatfolyamok 





e eofbit 
e failbit § 
e badbit 

e goodbit 


Ha a failbit be van állítva, az hibát jelent. A badbit komoly, fatális hibát je- 
lent. Ha valamilyen formátummal kapcsolatos hiba történt, akkor azt a fail- 
bit jelzi, ha adatvesztés vagy hasonló szintű hiba lépett fel, akkor a badbit ér- 
téke egy. Ha az eofbit be van állítva, akkor az adatfolyam elérte az állomány 
végét. Ilyenkor a failbit is automatikusan beállítódik. A goodbit konstans azt 
jelzi, hogy a fenti hibák közül egy sem lépett fel, vagyis ez nem tekinthető 
önálló jelzőbitnek. 
A fenti jelzőbitek beállítását a clear tagfüggvény végzi: 


Sajnos a név elég félrevezető, leginkább setnek kellene hívni. A függvény be- 
állítja az argamentumban megadott jelzőbitet, míg a többit törli. Például a 





beállítja a failbit jelzőbitet, és törli a badbit és az eofbit jelzőbiteket. Ha egy- 
szerre több bitet szeretnénk beállítani, a bitenkénti vagy (1) operátort kell 
használnunk: 





Így töröljük a badbitet, a többit beállítjuk. Az alapértelmezett paraméter a 
goodbit, vagyis ha paraméter nélkül hívjuk meg a függvényt, akkor minden 
hibaállapot törlődik. Ez utóbbi funkció esetén a név is találó. 

Az állapot lekérdezése jóval egyszerűbb: minden bithez egy függvény tar- 
tozik. Az alábbi függvények mind bool visszatérési értékűek, és igazzal térnek 
vissza, ha az adott bit be van állítva: 


A good() akkor igaz, ha egyik hibabit sincs beállítva. Sajnos történelmi okok- 
ból a fail függvény akkor is igazzal tér vissza, ha a badbit van beállítva. En- 
nek a jó oldala az, hogy elég csak a fail függvény visszatérési értékét meg- 
vizsgálni, a rossz oldala, hogy ez nem következetes megoldás, és ezt a tényt 
fejből kell tudni, mert a kódból nem látszik. 














5. fejezet: A Css 1/0 alapjai — 


agyon s, hogy ha eg tfolyam bármelyik hibabitje beállítódik, ak- 
kor ö8 esés edmözs esne illetve írási művelet azon az adatfolya- 
mon hatástalan marad: lefut, de nem tesz semmit. A fenti példánkban, ha az 
egész szám helyett betűsorozatot adunk meg, például az ,aaaaa -t gépeljük be, 
a cin állapota hibás lesz, attól kezdve a cin. fail0 igazzal tér vissza. A második 
beolvasás lefut ugyan, de nem történik semmi, majd kiíródik a hibaüzenet, 8 

Az a rövidítés, hogy elég ellenőriznünk az adatfolyam-objektumot, a fail0 
hívás visszatérési értékének tagadásával azonos." Mivel a cin 22 valami ope- 
rátoros kifejezés értéke cin, kód tovább egyszerűsíthető: 





A C nyelvből megszokott , szűrők" (pl.: while ((ch-getchar())!--1)...) így Crt- 
ban az alábbi idiómában megjelenő formát öltik: 





A hibavizsgálat az eddigiekből következik: 





Sokszor tisztább, olvashatóbb kódhoz vezet, ha kiírjuk a függvényhívásokat: 





sztringbe olvasunk, és a konverzió során értesítjük a felhasználót, hogy rossz adatot adott 
meg, javítsa ki, 





" It vlajáonképe aaról van szó, hagy a raidr- és a! aperátor túl van terhelve dési 62 
Függvényszintaxis és túlterhelés aj ha 1 





5.1. A szabványos adatfolyamok 


Jóllehet az adatfolyamosztályok fel vannak készítve kivételkezelésre (lásd 10. Kivételke- 
zelés fejezet), ne használjuk ezt a lehetőséget, a hibakezelést a fent bemutatott állapotvizs- 
HALAHAL Végezzük CT [TETT es 





Természetesen nemcsak a fenti operátorokkal végezhetünk beolvasást és ki- 
írást. Az alábbi táblázat összefoglalja a beolvasást támogató fontosabb tag- 
függvényeket, illetve C-beli megfelelőjüket. Itt nem ismertetjük az összes tu- 
lajdonságot, az istream vagy a basic istream osztályok dokumentációiban bő- 
vebb leírást találhatunk. Az alábbi függvényeknél, ha a visszatérési érték az 
adatfolyam, annak állapota jelzi az esetleges hibát. 





int istream::get() fgetchar Visszatérése a beolvasott karakter 
vagy EOF 
getline fgets Egy sor olvasása sor végéig. 0-4--- 


ban más határoló karakter is lehet 





read fread 
unget, putback ungetc 


Bináris adat beolvasása 





Az utolsó karakter visszahelyezése 
az adatfolyamba 





A Ct4 szabványos könyvtára tartalmaz egy string osztályt, amely szükség 
szerint változtatja a méretét: ha karaktereket fűzünk hozzá, automatikusan 
elvégzi a szükséges helyfoglalást. Ha egy ilyen sztringet szeretnénk beolvasni, 
természetesen használhatjuk a 22 operátort. Ilyenkor azonban az olvasást a 
szóköz karakter is megállítja (ez a scanf függvényre is jellemző 765 formátum- 
sztring esetén). Ha olyan sztringet szeretnénk soronként beolvasni, amely 
szóközt is tartalmaz, akkor az std::getline függvényt használhatjuk: 








55 A kivétel ugyanis akkor hívódik meg, ha a failbit beállítódik, Mint említettük, ez megtör- 
ténik az állomány végére érve is, ami kivételt eredményez. Az állomány vége pedig nem 
olyan hiba, amelyet catch blokkban kellene kezelnünk. 














5. fejezet: A Cr I/O alapjai 
Kiírás esetén az alábbi táblázat szolgál útmutatóul: 





fputchar Visszatérése a beolvasott karakter 





put 
vagy EOF 
write fwrite Bináris adat beolvasása 


eget 


A sztringek kiíratása esetén a cc operátort használjuk, arra nincs külön tag- 
függvény. 


5.2. Manipulátorok és formázás 


Az adatfolyam-objektumoknak — mint a legtöbb objektumnak — természetesen 
vannak tagfüggvényeik, amelyekkel beállíthatjuk az állapotát. adatokat ol- 
vashatunk és írhatunk, valamint egyéb műveleteket végezhetünk az adatfo- 
lyamon. Ugyanakkor az adatfolyamok manipulálásának nem ez az egyedüli 
módja: használhatunk úgynevezett manipulátorokat. Emlékezzünk vissza, 
hogy a kimeneti adatfolyam bufferét kétféleképpen is kiüríthettük: 


zség kögészéei gs. 





vagy a 


TAEGÁEL ETTE TO LELTE RETTENET E KASTÉLY 51 (letes eve egve 


függvényhívással. A különbség csak annyi, hogy az első esetben manipulátort 
használtunk, a másodikban tagfüggvénnyel értük el a kívánt funkciót. Az DO 
manipulátor (//O manipulator) egy olyan adatfolyam-módosító speciális ob- 
jektum, amelyet a szokásos kiviteli (c0) és bemeneti (25) operátorok argumen- 
tumaként alkalmazunk az adatfolyamokra. Az előre definiált manipulátorok az 


állományban és az std névtérben találhatók: vagy kiírjuk a using namespace 
std;-t, vagy mindenhol kiírjuk az std:: előtagot. 2 
Egy másik gyakran használt manipulátor például az endi, amely elhelyez 
egy sor vége karaktert az adatfolyamban, majd kiüríti a buffert. Az ends egy 
sztring vége ("109 karaktert helyez el az adatfolyamban. Az eddig ismertetett 
SUN GÁGTT csak kimeneti adatfolyamokra alkalmazhattuk. Említettük, 
ogy a cin alapértelmezett beállítása, hogy bizon én, jel- 
yos műveletek esetén, je: 
lemzően számok beolvasásakor, elhagyja a whitespace karaktereket. Ezt a tu- 
lajdonságát a noskipws manipulátorral változtathatjuk meg: 





5.2. Manipulátorok és formázás 





Ha ideiglenesen mégis szeretnénk figyelmen kívül hagyni ezeket a karakte- 
reket, akkor a ws manipulátort használhatjuk, amely az ő pozíciójában, jelen 
esetben a beolvasott adat elejéről , elnyeli" a whitespace-eket: 


Az alapértelmezett állapotot visszaállítani a skipws manipulátorral tudjuk. 
Vegyük az alábbi printf hívást, amely egy komplex számot ír ki négy tize- 
desjegy pontossággal, és nyolc minimális mezőszélességgel: 





Mi a megfelelője ennek C----ban? Íme: 





Ebből a setprecision, a setiosflag, a setw és az endl manipulátorok. Van, ame- 
lyiknek van paramétere (például setprecision), és van, amelyiknek nincs (end). 
Ha több olyan tulajdonságunk van, amelyet vagy beállítunk, vagy tör- 
lünk, akkor érdemes ezeket a tulajdonságokat egy egész típus bitjeinek meg- 
feleltetnünk. Például az ios::fixed egy jelzőbit. A jelzőbitek (flags) olyan bi- 
tek, amelyeket beállíthatunk (,eggyé tehetünk"), vagy törölhetünk (,0"-ra ál- 
líthatunk). Minden bithez tartozik egy bináris szám: ebben a bináris számban 
csak az a bit egyes, ahányadik biten az adott tulajdonságot beállítjuk. Ha egy 
kétbájtos változó első bitjén tároljuk az egyik tulajdonságot, a második biten 
a második tulajdonságot, a 0x0001 az első tulajdonság jelzőbitjéhez tartozó 
bináris szám, 0x0002 a második tulajdonsághoz tartozó szám. Ezeket a szá- 
mokat konstansként szokták megadni, példánkban ilyen volt az ios::fixed.?? 
Ha beállítunk egy jelzőbitet, akkor ezt a számot VAGY kapcsolatba hozzuk az 
eddigi beállításokat tartalmazó két bájttal, ha törölni szeretnénk, akkor a bi- 
tenkénti negáltját ÉS kapcsolatba hozzuk az addigi beállításokkal. Mivel fá- 
radságos lenne több szóval utalni a jelzőbiteknek megfelelő konstansokra, a 
gyakorlatban ezeket is jelzőbiteknek nevezzük: például az ios::fixed jelzőbit. 
Előfordul az is, hogy egy tulajdonságot több biten tárolunk. Ilyenkor egy 
olyan bináris számot adunk meg, amelynek az egyes tulajdonságokat megha- 
tározó bítjei egyesek, vagyis az egyes bitekhez tartozó konstansok VAGY kap- 
csolataként áll elő. Ezt a bináris számot maszknak (mask) nevezzük. 





19 Ennek az értéke a jelenlegi Dinkumware STL verzióban 0x2000, ami nullától számozva a 
13. bitnek felel meg. 
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5. fejezet: A Cs I/O alapjai 


Ebben a fejezetben a jelzőbitek az adatfolyam-objektum egyes tulajdonsá- 
gait jelentik, az ios::fixed jelzőbit beállítása esetén tizedes tört alakban írat- 
juk ki a számokat. A C4- [/0-hoz kapcsolódó jelzőbitek az ios nevű osztályban 
vannak definiálva. 

Az alábbi dolgokat formázhatjuk: 

e — mezőszélesség; 

e a kitöltő karakter (alapértelmezett: szóköz); 

e — igazítás (jobbra, balra); 

e — az egész számok számrendszere (decimális, hexadecimális, oktális); 

e — a lebegőpontos számok formátuma (fix, tudományos, általános); 


e — mutassa-e a t jelet, a helykitöltő nullákat, illetve az egész számok 
számrendszerének alapját (ezeket külön-külön állíthatjuk); 


e — kis- vagy nagybetűk legyenek-e a normál alak E-je és a hexadecimális 
számjegyek. 


A formázás esetén is kétféle módon érhetjük el a kívánt hatást: a cout/cin tag- 
függvényeivel vagy az adatfolyamba helyezett manipulátorokkal. 

A következő példa beállítja, hogy a lebegőpontos számok tizedes tört 
alakban jelenjenek meg: 





vagy: 





Ekkor a kimenet 3.140000. Most kikapcsoljuk a fix mezőszélességet. Egy jel- 


zőbitet a resetiosflags manipulátor vagy az unsetf tagfüggvény segítségével 
törölhetünk. 


vagy 

Ilyenkor az eredmény 3.14. A normál alakos kiírást az ios::scientific jelzőbittel 
állíthatjuk be. A 3.14 ábrázolása normál alakban. TE ANEAS az 
tos:rscientific jelzőbitet) 3.140000e-000. Ha egyik jelzőbit sincs beállítva, ak- 
kor az adatfolyam a legjobb formázást próbálja kiválasztani egy adott számra 


5.2. Manipulátorok és formázás 


annak nagyságától függően (csak a nagyon kis és nagy számok jelennek meg 
exponenciális alakban). Ha a két tulajdonságot egyszerre szeretnénk állítani, 
az ios:-floatfield maszkot használhatjuk. Az ios::floatfield az ios::scientific és 
az ios::fixed jelzőbitek bitenkénti VAGY kapcsolataként áll elő. Ha mindkét 
jelzőbitet törölni szeretnénk, akkor ezt az alábbi módon tehetjük meg: 


( cout ser 








vagy 


. cout.unsetf(Cios::floatfieldd; 





A fenti példában jól látható, hogy a lebegőpontos kiíratáshoz a floatfield maszk 
kapcsolódik, vagyis azt kell alapértelmezésre állítani. 

Egy további példa manipulátorokra számok különböző számrendszerek- 
ben való kiíratása. A példa sorra tizenhatos, nyolcas és tízes számrendszer- 
ben írja ki a megadott számot: 


int n -— 12; 928 
cout cc hex cen ee! Tt 

cout cc oCct cc Nn cc iv 
cout cc dec cc n cc endl; 








A bináris formátum nem támogatott. Az alapértelmezett a tízes számrend- 
szer, az alapértelmezéshez a basefield maszkot használhatjuk, amely a dec, 
hex és oct bitenkénti VAGY kapcsolatából áll. 

Az alábbi táblázat összefoglalja a formázáshoz használt gyakoribb mani- 
pulátorokat és a megfelelő tagfüggvényeket. 





Manipulátor Tagfüggvény Leírás 
setfill fil 





beállítja a kitöltő karaktert, amely, 
ha a szám kisebb helyet foglal, mint a 
minimális mezőszélesség, kitölti az 
üres helyet 











setw width beállítja a minimális mezőszélessé- 
get; nem tartja meg a beállítást, csak 
a soron következő műveletre 

setprecision precision a kiírandó tizedesjegyek beállítása 

setiosflags setf beállítja a megadott jelzőbitet (az ed- 


digi beállításokkal bitenkénti VAGY 
kapcsolatba hozza a paraméterét) 
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5. fejezet: A Cr 1/0 alapjai 


2. fejezet: A Grr VR GAPYB e mmmitmmetááeásáááááásátstát 





resetiosflags unsetf törli a jelzőbitet (a megadott paramé- 
ter bitenkénti negáltjával ÉS kapcso- 
latba hozza az eddigi beállításokat) 














hex tizenhatos számrendszer 

oct nyolcas számrendszer 

dec tízes számrendszer 

showbase mindig mutassa a számrendszer elő- 


tagját (Ox, 0) 














noshowbase sose mutassa a számrendszer előtagját 

showpos pozitív számok esetén mutassa a t 
előjelet 

noshowpos pozitív számok esetén ne mutassa a t 
előjelet 

uppercase nagybetűs kiírás: E (a számok expo- 


nenciális alakjában), X (hexadecimális 
számok előtagja) és az A, B, C, D, E, F 
hexadecimális számjegyek 








nouppercase kisbetűs kiírás a fenti esetekben 





boolalpha a bool típus formátuma szöveges 
(true, false) 





noboolalpha a bool típus formátuma szám (0, 1) 





Például egy bájt szokásos hexadecimális megjelenítését (két karakter, ha egy- 
jegyű a szám, akkor az első nulla, majd egy szóköz) alapértelmezett beállítá- 
sokról indulva az alábbi módon végezhetjük: 





A jelzőbitek a mezőszélesség kivételével mindaddig megtartják beállításaikat, 
ameddig meg nem változtatjuk őket. Azokat a tulajdonságokat, amelyeket 
nem állíthatunk külön tagfüggvénnyel vagy manipulátorral, jelzőbitként a 
setiosflagsíresetiosflags manipulátorokkal, illetve a setflunsetf tagfüggvények- 
kel állíthatjuk be. Ezeket a jelzőbiteket az alábbi táblázat foglalja össze: 
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left balra rendez 

right jobbra rendez 

internal az előjel balra, a szám jobbra 

dec tízes számrendszer 

hex tizenhatos számrendszer 

oct nyolcas számrendszer 

showbase mindig mutassa a számrendszer előtagját (0x, 0) 
showpos pozitív számok esetén mutassa a 6 előjelet 

uppercase nagybetűs kiírás: E (a számok exponenciális alakjában), 


X (hexadecimális számok előtagja), és az A, B, C, D, E F 
hexadecimális számjegyek 

















fixed tizedes tört alak 

scientific exponenciális alak 

showpoint mindig kiírja a tizedesvesszőt/pontot 
boolalpha a bool típus formátuma szöveges 
unitbuf minden írási művelet után törli a buffert 





Útmutató: Összefoglalva a Cr adatfolyamokkal kapcsolatos formázásokat az alábbi mond- 
ható el: 


— — Jó néhány beállítást manipulátorokkal szabályozhatunk, amelyeket egyszerűen a cc 
és 22 operátorok argumentumaként használunk. A minimális mezőszélesség kivételé- 
vel minden beállítás megőrződik. 


— — Néhány beállításnak nincs külön manipulátora, ezek a setiosflags és a resetiosflags 
paramétereiként megadott jelzőbitek megadásával állíthatók. 


— — A manípulátoroknak megfelelő műveleteket az adatfolyam tagfüggvényeivel is elvé- 
gezhetjük. 





Természetesen a fenti manipulátorokat és jelzőbiteket nem kell fejből tud- 
nunk, csak a gyakrabban használtakat, amelyeket gyakori mivoltuk miatt 
úgyis megjegyzünk. Reményeink szerint a fenti példák és az áttekintés ele- 
gendő rálátást biztosít a manipulátorok használatára, a fordítók dokumentá- 
ciói pedig mindig rendelkezésre állnak. A modern fejlesztőeszközök pedig au- 
tomatikusan kiegészítik a félig beírt manipulátorokat is. 


a 
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5. fejezet: A Cs I/O alapjai 


5.3. Állománykezelés 


A C szabványos állománykezelése egy FILE" típusú leíró köré csoportosul, 
amelyet a fopen függvény ad vissza. Amikor egy megnyitott állományon va- 
lamilyen műveletet akarunk végezni, akkor át kell adnunk a leírót, hogy az 
adott függvény tudja, melyik állományon kell elvégezni azt a bizonyos műve- 
letet. A C4- megoldásban a leírót egy objektum zárja egységbe, és annak tag- 
függvényei segítségével végezhetjük el az állományműveleteket. A tagfüggvé- 
nyekben természetesen nem jelenik meg az állományleíró mint argumentum, 
hiszen tagváltozóként elérhető. 

A C4-4 az állománykezeléshez is adatfolyamokat használ, amelyeket ezút- 
tal az ifstream (bemeneti állomány-adatfolyam, input file stream), illetve az 
ofstream (kimeneti állomány-adatfolyam, output file stream) osztályok repre- 
zentálnak. A kétirányú adatfolyamot az fstream osztály valósítja meg. Mivel 
ezek is egyfajta adatfolyamok, az előző fejezetben ismertetett szabványos 
adatfolyamon végzett műveletek az állományok esetén is érvényesek."9 Mivel 
az objektumorientált konstrukciók lehetővé teszik a konstruktorok és destruk- 
torok használatát, az állományok megnyitását a konstruktorok végzik, lezárá- 
sát pedig a destruktorok. Így sokkal biztonságosabb az állománykezelés. Néz- 
zünk erre egy egyszerű példát, amely karakterenként átmásol egy állományt! 





finclude cfstream 
using namespace std; 


ifstream from("c: adat .dat") ; 
íf(!from) 


3 
//Hibakezelés 


) 
ofstream to ("d:Wadat.dat"); 
if(1to) 


1 
5 //Kibakezelés 


char ch; 


while(from.get(ch)) 
Vo. PURCOKOZ E MÉTÉN LESETT 





4 Pontosabban azért, mert a fájladatfolyamok a basic ifstreamchar2, illetve basic. of- 
stream schar) specializációkként jelennek meg, amelyek rendre a basic istream char?, 
illetve basic, ostream schar? osztályokból származnak. Az általunk említett osztályok az 
alábbi típusdefiníciókból származnak: : 

typedef basic. istream char: istream; 77 a cin típusa 

typedef basic. ostream ccharxostream; 77 a cout, cerr, clog típusa 
typedef basic. ifstream Schar? ifstream; 

typedef basic ofstreamcchar? ofstream; 

typedef basic fstream char? fstream; 





5.3. Állománykezelés 





Az állomány-adatfolyamosztályok definíciói az fstream fejlécfájlban találhatók 
az std névtérben. A megnyitandó állomány nevét a konstruktorban adhatjuk 
meg, a hibakezelés a már megszokott módon, az adatfolyam-objektum vizsgá- 
latával végezhető. 

Szokás szerint többféle üzemmódban lehet megnyitni egy állományt. Eze- 
ket jelzőbitekkel állíthatjuk be, amelyeket a konstruktor opcionális második 
paramétereként adhatunk meg. Akárcsak a formázással kapcsolatos jelzőbi- 
teket, ezeket is az ios:: előtaggal kell ellátni. Több jelzőbit esetén azok biten- 
kénti vagy (]) kapcsolatát kell megadni. A jelzőbiteket és jelentésüket az 
alábbi táblázat foglalja össze. 






in megnyitás olvasásra 




















out megnyitás írásra 

app , append" (hozzáfűzés), a kiírt adatot az állomány végé- 
hez fűzi 

ate , at end" (a végére), megnyitás után az állomány végére 
pozícionál 

trunc ,truncate" (levág), az addigi adatokat törli az állomány- 
ból 

binary Bináris állomány-hozzáférés 





A bináris és a szöveges hozzáférés megkülönböztetésének csak bizonyos ope- 
rációs rendszerek alatt van értelme. Egyes platformok (OS/2, a Windows kü- 
lönböző verziói) esetén ugyanis nem egy karakter a soremelés (§9n), hanem 
kettő (Nr). Unix rendszerekben és így történeti okok miatt a C-ben és a 
Ct-4-ban csak egy karakter jelöli a sor végét. Ezt a kettősséget úgy oldják fel, 
hogy szöveges mód esetén a (rNn) karaktereket használó platformokon a két 
karakter helyett csak egy karaktert (wn) olvasnak be a függvények, illetve ki- 
íráskor a (Xn) helyett ("rXn)-t írnak ki. Bináris üzemmódban nincs ilyen kon- 
verzió. Nézzünk egy példát bináris állománykezelésre! 
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5. fejezet: A Crr I/O alapjai 





A fenti program bemutatja, miként lehet tömböt, illetve egyetlen bájtot kiírni 
(a C fwrite megfelelője). Az alábbi példa visszaolvassa a kiírt adatokat. 


:binary); 












ja a Tanétségel JEZÖBTE KO ÉÍGÁGIÓkat; aze: 
vagy. az open függvénynek adhatunk át a megnyitás 























in JABA f csak olvasás 

out sw csak írás 

outlapp ki: 8 írásra (hozzáfűzi a már meglé- 
vő állomány végéhez) 

outltrunc "w" írásra az eddigi tartalom törlé- 
sével 

inlout dee írásra és olvasásra 

inloutl trunc "we írásra és olvasásra az eddigi 
tartalom törlésével 

binary DA elol a fenti kombinációk mindegyi- 
kéhez hozzáadhatjuk 

ate Nincs megfelelő fopen a fenti kombinációk mindegyi- 


paraméter, C-ben meg- " kéhez hozzáadhatjuk 
nyitás után az állomány 
végére kell pozícionálni. 





Bizonyos adatfolyamok esetén pozícionálásra is van lehetőségünk. Az állomá- 
nyon belüli pozícionálást az alábbi tagfüggvényekkel végezhetjük: 





tellg0 tellpO 





visszaadja az aktuális 
pozíciót 

seekg(pozíció) seekp(pozíció) a megadott pozíciót 
állítja be 





seekg(eltolás, pozíció) seekp(eltolás, pozíció) az állomány elejéhez, 
pozíció: ios::beg (eleje), — — végéhez, illetve az aktuá- 
ios::end (vége), ioszzeur —— lis pozícióhoz képest re- 
(aktuális pozíció) latív pozíciót állít be 














Mivel az olvasás és az írás aktuális pozíciója különbözhet, a pozicionálásra két- 
féle függvény létezik. A bemeneti és kimeneti adatfolyamok függvényei másképp 
végződnek: a bemeneti adatfolyamok esetén olvasási pozicionálást (get) jelent, 
míg a kimeneti adatfolyamok esetén írási pozicionálásról (put) van szó. A tell 
függvények visszatérési típusa pos type, amely nem egész jellegű típus: nem ad. 
hatunk hozzá számot. Viszont eltárolhatjuk a pozíciót, ami az egyparaméterű 
seek függvényeknek átadható. A kétparaméterű seek függvények első paraméte- 
re viszont előjeles egész, amely a relatív pozíciót bájtokban adja meg. 

Fontos, hogy a programozó felelőssége, hogy ezek érvényes pozíciót jelent- 
senek, különben a függvény viselkedése nem definiált. Szintén ez a helyzet, 
ha a pozícionálás egy adott adatfolyamra nem definiált: például a cin, cout, 
cerr és clog esetén nem használhatunk pozicionáló függvényeket. 

Az istream és ostream adatfolyamok mindegyike megnyitható írásra és 
olvasásra (in lout kombinációk). Az értelmezett műveletek azonban az adatfo- 
lyamok mögött lévő buffer típusától függenek (például nyomtatóhoz, soros 
kommunikációhoz vagy fájlrendszerbeli állományokhoz rendelt buffer). Fájl- 
rendszerbeli állomány esetében nem válthatunk akárhogyan az olvasás és az 
írás között. Általában egy pozicionáló műveletet kell végeznünk (tipikusan 
seekg/ seekp (0, ios::cur)), amikor váltunk az egyik műveletről a másikra, ki- 
véve, ha az állomány végén tartunk, akkor erre nincs szükség. 


5.4. Egyéb műveletek 


Az átirányítás igen kényelmes funkció, amelyet természetesen C-t--ban sem 
kell nélkülöznünk. Például C-ben a szabványos hibakimenetet (stderr) az 
freopen függvénnyel átirányíthatjuk egy tetszőleges állományba. 

CtH-ban ezt az alábbi módon tehetjük meg. Elsőként megnyitjuk az állo- 
mányt, és az átirányítandó adatfolyam formázási beállításait (például hexadeci- 
mális kiírás, lásd előző fejezet) átmásoljuk a megnyitott állomány adatfolyamába. 

Korábban említettük, hogy az adatfolyam mögött létezik egy adatfolyam- 
buffer, amely kezeli az adatfolyamba beírt adatokat. Az átirányításkor ezt a 
két szintet használjuk ki. Az adatfolyam-buffer egy objektum, amelyet az 
adatfolyamtól az rdbuf tagfüggvény paraméter nélküli változatával kérdezhe- 
tünk le, illetve az egyparaméteres verziójával állíthatunk be. Az adatfolyam- 
buffer-objektum lefoglalásáért és felszabadításáért az adatfolyam objektum 
felel. Így két adatfolyam nem tartalmazhatja ugyanazt az adatfolyambuffer- 
objektumot felszabadításkor, ugyanis az egyik adatfolyam-objektum destruk- 
torának sikerül felszabadítania, a második pedig egy már felszabadított adat- 
folyambuffer-objektumot próbálna felszabadítani. Ezért a példában eltároljuk 
a clog eredeti bufferét. Ezt az adatfolyambuffer-objektumot majd lecseréljük 
az állomány bufferére, hogy a clog adatfolyam az állomány adatfolyambuffer- 
objektumába írjon. Ez az átirányítás lényege. Végül visszaállítjuk a clog ere- 
deti, elmentett adatfolyambuffer-objektumát, és így mindkét adatfolyam-objek- 
tum (/ogFile, clog) a saját, eredeti adatfolyambuffer-objektumát szabadítja fel. 





5.4. Egyéb műveletek 





u ása átirányítási mechanizmusának megértéséhez tekintsük az alábbi 
példát! 





A fenti programrészlet jellemzően a main függvény elején és végén fordulhat 
elő lehetővé téve, hogy a program mindössze egy sor módosításával beállítha- 
tó helyre naplózzon. 

Alapértelmezésben a C--t előre definiált adatfolyamai (cin, cout, cerr, clog) 
szinkronizálva vannak a C megfelelő adatfolyamaival (a cin a stdint, a cout az 
stdoutot a cerr és a clog az stderrt használja). Ez implementációtól függően 
lassíthatja a Ct- [/0-t. Ezért ha nincs szükségünk erre a funkcióra, az 
ios::sync. with. stdioffalse) hívással kikapcsolhatjuk, ami implementációtól 
függően sebességnövekedést jelenthet. Fontos, hogy ezt az első [/D művelet 
előtt kapcsoljuk ki, különben az implementációtól függ, hogy mi történik. 
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HATODIK FEJEZET 


Operátorok és túlterhelésük 


Mint már említettük, a Ct- nyelv egyik sajátos célja, hogy a programozó által 
megadott osztályok hasonló lehetőségekkel rendelkezzenek, mint a beépített 
típusok. Ezt típustámogatásnak neveztük. A beépített típusokra számos 
, testreszabott" művelet értelmezhető, gondoljunk itt a négy alapműveletre: az 
összeadást másképpen kell végrehajtani egy egész típusú változón, mint egy 
lebegőpontos típusún. Ezekre a típusokra magától értődő az összeadás operá- 
torként való értelmezése, hiszen a matematika szabályai precízen definiálják. 
A matematika szabályai ugyanakkor lehetővé teszik, hogy komplex számokra 
vagy akár mátrixokra is értelmezzük az összeadást és egyéb műveleteket, 
amelyeknek a szokásos jelölése megegyezik az egész vagy valós számokon 
végzett művelet jelölésével. Ezek a Ct-4 nyelvben operátoros kifejezések: az 
összeadás, szorzás és egyéb operátorok végzik az adott műveletet. Felmerül 
tehát a kérdés: ha írunk egy komplex számokat vagy mátrixokat reprezentáló 
osztályt, hogyan oldjuk meg, hogy le tudjuk írni a 21422 kifejezést, ahol az 
összeadás operátor argumentumai Complex típusú objektumok. Megoldás- 
ként a C-hez képest új C-t nyelvi konstrukció áll rendelkezésünkre: az ope- 
rátorok túlterhelése (operator overloading). 


6.1. Az operátorokról általában 


A C nyelvben az operátorok az argumentumaikon végeznek műveletet, az 
adott művelet eredményét a visszatérési értékük feldolgozásával használhat- 
juk. Továbbá némely operátorok az argumentumaik értékét is megváltoztat- 
ják, ezt az adott operátor mellékhatásának nevezzük. Vagyis a ct-t kifejezés 
esetén a c változó a tt operátor argumentuma, az operátor visszatérési érté- 
ke a c változó eredeti értéke, mellékhatásként az operátor kiértékelése után a 
c változó értéke eggyel több lesz. 

Az operátorok kiértékelésének sorrendjét speciális szabályrendszer rögzí- 
ti, amelyet zárójelekkel befolyásolhatunk. A műveleti sorrend leírását a jól 
ismert precedenciatáblázat tartalmazza, az azonos precedenciájú műveletek 
kiértékelésének irányát az operátor asszociativitása határozza meg. Néhány 
művelet esetén csak a fordító által használt nyelvtan lehet a segíts günkre: 
az azbce?dze:f-g kifejezés kiértékelése az a-((bcc)?(d7e):(f-g)) kifejezésével 
azonos módon történik. 

















Ezeket a kifejezéseket ne használjuk zárójelek nélkül, sőt, bonyolultabb 
kifejezések esetén mindig használjunk zárójelet az olvashatóság végett. Szá. 
mos fejlesztői csoport kódolási konvenciói pedig kifejezetten tiltják a hasonló 
kifejezések használatát. A Ct-t nyelv operátorainak precedenciája és asszoci. 
ativitása az , A" függelékben található. 

A Cs nyelv a C-hez képest bevezet néhány új operátort. Ezek közül a ha- 
tókör operátorral (::) már találkoztunk. A pointer-tag operátorokat (." és 5") 
a 6.6. A pointer-tag operátorok részben ismertetjük, a további operátorokat a 
konverzióknál (8.3. A C4- típuskonverziós operátorai rész: const cast, dyna- 
mic. cast, reinterpret cast, static cast), illetve a kivételkezelésnél (10. Kivétel. 
kezelés fejezet: throw) találjuk. A futásidejű típusazonosítással ebben a 
könyvben nem foglalkozunk, így a typeid operátorral sem. 

A Cs4 az operátorok működésében nagyon rugalmas. A következő feje- 
zetben rátérünk a saját operátorok írásának lehetőségeire, vagyis az operáto- 
rok túlterhelésére. 


6.2. Függvényszintaxis és túlterhelés 


Az argumentum és a visszatérési érték kifejezés hallatán jogosan jutnak 
eszünkbe a függvények. A C nyelv keretein belül azonban egy fontos különbsé- 
get kell tennünk: a függvény nem képes mellékhatásra, a C nyelvben ugyanis 
csak érték szerinti paraméterátadás van, nem tudjuk megváltoztatni egy változó 
értékét, csak ha a változóra mutató pointert adunk át. A C----ban nincsenek 
ilyen korlátaink: a referencia szerinti paraméterátadás , mellékhatásra" is képes. 
Így írhatunk a postfix t-t operátor működésének megfelelő függvényt is: 





Ezek után az alábbi két kifejezés működése ekvivalens: 


Így a függvények és az operátorok i 
é 2 különbsége mindössze a kiértékelés sza: 
ft e tesestn jelentkezik. Ennek megfelelően az operátorokat felfoghat- 
inbálytsatsát; ze az nksetsepmáát ess 
7 ee ka A JOTT ezt szintaktikailag is támogatja: 37 
"rt operátort, amelyet kétféleképpen A plsesján firsgagegál saját tájgászáág ús 





6.2. Függvényszintaxis és túlterhelés 


ke 


A Cs4-ban az operator kulcsszó, ezzel adjuk meg, hogy egy speciális függ- 
vényről van szó. Nézzünk egy további példát: 





Sietve jegyezzük meg, hogy a fenti példák operátoros írásmódjai nem fordul- 
nak le int paraméterek esetén. Sőt, a beépített típusokra egyáltalán nem 
használhatjuk a függvényszintaxist. A függvényszintaxis lényege ugyanis, 
hogy a függvényekkel azonos módon definiálhatjuk az operátorok működését. 
Nem az a célunk, hogy a már bevált operátorok működését megváltoztassuk, 
hanem hogy az operátorok működését az általunk definiált típusokra is meg- 
adhassuk! Ezért az argumentumok típusai között legalább az egyiknek nem 
beépített típusnak kell lennie. 

Mivel az operátorok speciális függvények, és a függvénynevek — különbö- 
ző argumentumok esetén — túlterhelhetők, a függvénynevekhez hasonlóan az 
operátorok neveit is túlterhelhetjük. Ha szeretnénk az összeadás operátort 
definiálni a beépített double és az általunk írt komplex szám típusok között, 
az alábbi módon tehetjük meg: 





Ebben az esetben már működik a fenti függvényszintaxissal megadott operá- 
tort hívása is. 

Vizsgáljuk most meg azt a helyzetet, amikor két komplex szám közötti 
összeadást szeretnénk definiálni! Az eddigiek alapján az alábbi módon definiál- 


nánk az operátort: 





Ugyanakkor emlékezzünk arra, hogy minden nem statikus tagfüggvénynek 
van egy ,rejtett"? paramétere, amely megegyezik az osztály típusával. Így 
amikor a túlterhelendő operátor első paramétere olyan típus, amelyet mi 
írunk, akkor az operátort nem globálisan, hanem tagfüggvényként célszerű 
definiálni, és — természetesen — nem írjuk ki az implicit első paramétert. Ez 
az egységbe zárás alapelvének fényében igen elegáns megoldást tesz lehetővé. 
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Ezek után leírhatjuk az alábbi kifejezéseket, ahol a változók komplex típusú 
objektumot jelölnek: 





Az operátorok túlterhelését a továbbiakban egy példával illusztráljuk. 


6.3. Példa: egy komplex számokat 
megvalósító osztály 


pzs ést. ket 6 eeesettb o fene el denen d ol dey ÉSE SERÉRRTANNKAÉ SES te ts 
Feladat: Írjunk komplex számokat megvalósító osztályt! Tegyük lehetővé az alábbi művelet- 
csoportokat! 





1. Statikus műveletek 
Complex::Re(2): valós rész 
Complex::Im(2): képzetes rész 
Complex::Conjugate(z): konjugált 


2. Imaginárius egység használata 
2-Hir4:i-V-1 


Műveletek komplex számokkal 
z1422: komplex összeadás 

21-—z2: komplex kivonás 

21772: komplex szorzás 

71/22: komplex osztás 

—z: mínusz egyszeres 


3. 


4. Valós és komplex műveletek 
3.0z: összeadás valós számmal 
3.0—z: kivonás valós számból 

3.Osz: szorzás valós számmal 

3.0/z: valós osztása komplex számmal 


[/0 műveletek 
cout £k z: írás 
cin 55 z: olvasás 





6.3. Példa: egy komplex számokat megvalósító osztály 


Elsőként döntsünk az adatreprezentációról! A komplex számok esetében ez 
elég kézenfekvő: egy valós és egy képzetes részt kell tárolnunk. Mivel ezek 
tetszőleges értékeket tartalmaznak, kívülről nem lehet , elrontani", publikus- 
nak deklaráljuk őket. Az osztályt a ComplexNumbers névtérben helyezzük 
el.:! A Complex osztályt a konstruktorban inicializálhatjuk egy komplex ér- 
tékkel, valós értékkel, ha pedig nem adunk meg argumentumot, akkor lenul- 
lázódik. Ezt alapértelmezett függvényargumentumokkal meglehetősen ele- 
gáns módon meg tudjuk oldani. 








Az első műveletcsoport megvalósítása néhány statikus függvény implementá- 
cióját jelenti. A függvényeket a következőképpen definiáltuk: 





Ezzel többek között lehetővé tesszük az alábbi függvényhívást: 





A második műveletcsoport lehetővé teszi, hogy az imaginárius egységet (ame- 
lyet gyakran i-vel, néha j-vel jelölnek) a matematikai írásmódot megközelítő 
egyszerűséggel írhassuk le a programban alkalmazott műveletek során is. 

Ezért a fejlécfájlban az osztályon kívül externként deklarálunk egy ilyen 
nevű konstanst, és a cpp állományban definiáljuk: 





41 A névterekről részletesen a 9. fejezetben olvashatunk. 
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6. fejezet: torok és túlterhelésük 





A harmadik műveletcsoport jelenti tárgyalásunk szempontjából az egyik leg- 
lényegesebb csoportot. Mivel a műveletek első argumentuma komplex, az ope- 
rátorokat tagfüggvényként deklaráljuk. Érdemes megfigyelni, hogy a harma- 
dik műveletcsoport operátorainak nincsenek mellékhatásai, vagyis nem vál- 
toztatják argumentumaik értékét. Így a biztonságos programozás jegyében 
mind a paraméterek, mind a függvények konstansok lesznek. 





A függvények implementációi a matematika szabályait követik: 








6.3. Példa: egy komplex számokat megvalósító osztály 





Emlékeztetünk rá, hogy például a operátor esetén azért veszünk át kons- 
tans referenciát, hogy a függvényhíváskor ne másolódjon le az egész objek- 
tum, csak a címe. A visszatérése nem lehet referencia, hiszen a lokális válto- 
zóra nem adhatunk referenciát a függvényen kívülre. 

Érdemes egy kicsit elidőznünk a kétargumentumú mínusz operátor imple- 
mentációjánál. Mivel az egyargumentumú mínusz és az összeadás már rendel- 
kezésünkre áll, ezeket felhasználva megírhatjuk a kétargumentumú kivonást. 





Ugyanakkor az egyargumentumú - operátor hívása függvényszintaxissal is 
lehetséges lenne. 





Sőt, ebben a kifejezésben az összes többi operátort írhatjuk függvényalakban 
(itt már a this pointerre sincs szükség): 





Ezzel maradéktalanul megvalósítottuk a harmadik műveletcsoport műveleteit. 
Itt jegyezzük meg, hogy ennél valamivel többet is tettünk. A konstruktor itt 
nem részletezendő okok miatt lehetővé teszi, hogy ha a kétargumentumú ope- 
rátorok második argumentumként Complex helyett double típust kapnak, ak- 
kor Complex típussá konvertálódnak nulla képzetes résszel, az operátoraink ez 
esetben is megfelelően működnek. Megjegyezzük, hogy ez a típusú konverzió 
a negyedik műveletcsoportban nem működik. Erről a konverzióról részletesen 
a 8.2.1. Konverzió független típusok között fejezetben olvashatunk. 

A negyedik műveletcsoport hasonlóan kiemelkedően fontos az operátorok 
túlterhelése szempontjából. Itt arról van szó, hogy az első argumentum beépí- 
tett típus, így az operátort nem tudjuk tagfüggvényként definiálni. Ennek 
megfelelően globális operátorokat kell készítenünk. Az egységbe zárás alap- 
elvének hívei javasolhatnák erre a célra a statikus függvényeket, ám a Ctt- 
ban ez nem működik. Mivel néhány művelet felcserélhető, ezért kihasznál- 
hatjuk, hogy a másik irányt már implementáltuk a konstruktor és a harma- 
dik műveletcsoport segítségével. 














6. fejezet: Operátorok és túlterhelésük 


Mivel az osztás nem kommutatív, külön kell implementálnunk: 


6.3. Példa: egy komplex számokat megvalósító osztály 


A fenti operátor deklarációjával kapcsolatban magyarázatra szorul a függ- 
vény visszatérési értéke. Az adatfolyamot a kimeneti adatfolyamok, például a 
cout szokásos használata miatt kell visszaadnunk. Általában egy sorban több 
mindent kiírathatunk egyszerre a cc operátor ismételt alkalmazásával. Ír- 
junk át egy egyszerű kiíratást függvényszintaxisba! 





Mivel a globális / operátor szeretne hozzáférni a Complex osztály tagváltozói- 
hoz, ezért friendnek deklaráljuk a Complex osztályban. 





Ezzel lehetővé tettük a negyedik műveletcsoportban megjelenő operátoros ki- 
fejezések használatát. 

Az ötödik műveletcsőport az operátorok túlterhelése szempontjából nem 
új, mégis hasznos megfigyelnünk, miként kell együttműködnünk a Ct-t osz- 
tálykönyvtárával. A cout és a cin objektumok, melyek az ostream, illetve az 
istream osztályokat példányosítják. Ezeket az osztályokat előre megkapjuk a 
fordítóval, számos fordító esetén a forrásuk is a rendelkezésre áll. A fent em- 
lített osztályok túlterhelnek két operátort, nevezetesen a c£ és a 27 operáto- 
rokat. Szeretnénk, ha ezen operátoroknak lenne egy olyan verziója, amely 
Complex típust vár. Ugyanakkor az ostream, illetve az istream osztályokat 
nem mi írtuk, vagyis nem illik módosítani őket, még akkor sem, ha fizikailag 
a C-t forrás birtokában megtehetnénk. Ezért ismét globális operátort írunk. 
Mivel ezek a globális operátorok a tagváltozókat fogják kiírni, illetve azokba 
fognak adatot beolvasni, ismét frienddé kell tennünk őket. 

Vegyük először a kiíratást. Itt egyszerű dolgunk van, hiszen az ostream 
már létező tagfüggvényeit a szokásos módon használjuk: 
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Az átírásból rögtön látható, hogy a külső cc operátor csak akkor alkalmazha- 
tó, ha első argamentumának, a belső cc operátornak van visszatérési értéke, 
és akkor adja az egyszerűsítés nélküli kívánt eredményt, ha a visszatérési ér- 
ték pontosan a cout. 

A beolvasást az istream tagfüggvényeivel végezzük. Jelen példában csak 
az atitb alakú bevitelt támogatjuk, de a példa könnyen kiterjeszthető tetsző- 
leges beviteli formátumra. 


istream$ operators:(istreamé is, Complexg 2) 


double re, im; 


jus 484 
is 55 re; // valós rész 


char c 50 
isssz c; 7/ 4. jel 


if(c Is 4) : 
ís.clearCios::failbit); 
iss c; // di 


áf(rcAe 1) A Lt 
is.clear(Cios::failbit); 





ís sz cs.// "jel Ggss ő 
Ne Fte- hix) dapekhkó 
kéz is.clearCios: :failbit); 







is sz im; // képzetes rész. 
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6. fejezet: Operátorok és túlterhelésük 





Az alapvető megközelítés itt is az, hogy az istream már elkészített függvényeit 
használjuk a már meglévő típusokra, ugyanakkor itt hibajelzést és hibaellenőr. 
zést is végeznünk kell. Ha valami hiba történt, akkor az adatfolyam állapota 
nem lesz jó, vagyis a good() tagfüggvény hamis értékkel tér vissza. Ha magunk 
tapasztalunk hibát a beolvasáskor, ami abból adódik, hogy nem a kívánt formá. 
tumban kaptuk meg a komplex számot, akkor beállítjuk a fail bitet. A végén 
csak akkor fogadjuk el a számot, ha minden megfelelő volt, vagyis a good() tag- 
függvény visszatérése igaz. Mivel az adatfolyam-objektumot visszaadjuk, an- 
nak állapotát lekérdezve a hívó is meg tudja állapítani, hogy történt-e hiba. 
Ezzel befejeztük a komplex számot kezelő osztály implementációját. 


6.4. Speciális operátorok túlterhelése 


A fenti operátorok túlterhelése nem okozott különösebb nehézséget, ha a 
függvényszintaxist megszoktuk, és megtanultuk alkalmazni. Van azonban 
néhány operátor, amelynek túlterhelése valamilyen szempontból speciális 
bánásmódot igényel. 

Ezek közül legfontosabb az egyenlőségjel operátor. A probléma azonos a 
másolókonstruktor esetében előkerült megfontolásokkal, a mély, illetve sekély 
másolat kérdéskörével. Mivel a sekély másolat az esetek többségében elegendő, 
az operator—-nek is van egy alapértelmezett implementációja, 1? amely — a for- 
dító számára rendelkezésre álló információ miatt — sekély másolatot készít. 
Ha mély másolatra van szükségünk, akkor meg kell írnunk az operator—-t. 
Fontos, hogy dinamikus adattag esetén írjunk operator—-t, akár olyat, amely 
kiírja, hogy nincs implementálva, és leállítja a programot. Így sok rejtélyes hi- 
bától megmenthetjük magunkat és programozó kollégáinkat. Vagyis a dinami- 
kus adattagokat tartalmazó osztály feladatlistája egy újabb elemmel bővült. 


Útmutató: Dinamikus adattagot tartalmazó osztály esetén mindig írjunk 
— — konstruktort, amely inicializálja a pointert; 
—  másolókonstruktort, amely vagy elvégzi a másolást, vagy hibaüzenetet ad; 
—  destruktort, amely felszabadítja a pointer által mutatott területet; 
— — operator--t, amely elvégzi a másolást vagy hibaüzenetet ad. 





"A teljesség kedvéért megjegyezzük, hogy referencia vagy konstans tagváltozó esetén, illetve 
ha az ősosztályban privát operátor- található, a fordító nem generál operator—-t. Az első két 
ben az ösosztály oserele jer odítans megváltoztathatatlansága az oka, a harmadik eset: 
Viszont a genárált kód este hane, sg 5 s 





6.4. Speciális operátorok túlterhelése 
Láthatjuk, hogy a másolókonstruktor és az operator- igen hasonlít egymásra: 





e Mindkettő egy másolatot készít az objektumról. 
a A fordító alapértelmezett, sekély másolatot készít, ha nem írjuk meg. 
s A dinamikus osztályok esetén jellemzően mindkettőt meg kell írni. 


Nézzük meg a 3.5. Dinamikus adattagot tartalmazó osztályok fejezetben meg- 
írt IntFifo osztály kiegészítését operator—-vel! 





Az operátor visszatérési értéke azért IntFifo típusú, mert — hasonlóan a kiíra- 
tásnál felüldefiniált cc operátorhoz — szeretnénk használni az f/1-f2-f3 kife- 
jezést. Az első pár sor rávilágít, hogy az egyenlőség operátor egy nagyon fon- 
tos dologban különbözik a másolókonstruktortól. Míg a másolókonstruktor 
esetén az adott objektum a másolókonstruktorral jön létre, az operator— ese- 
tén az objektum már készen van. Ezért lehetséges, hogy valaki az /-/ kifeje- 
zést írja le, ami a kódot megvizsgálva egyértelműen nagyon kellemetlen kö- 
vetkezményekkel járhat. Ezt vizsgáljuk az első if-szerkezetben. A másik fon- 
tos dolog, hogy az adott objektumnak, amelyet egyenlővé teszünk egy másik- 
kal, már lehetnek dinamikus adatterületei, amelyeket fel kell szabadítani. 
Ezt vizsgáljuk a második feltételes szerkezettel. 
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6. fejezet: Operátorok és túlterhelésük 


Ugyanakkor a kód — ezt a két fontos részt leszámítva — nagyon hasonlít a má. 
solókonstruktorhoz, és a kód megkétszereződése sohasem szép. Mivel a konst- 
ruktort nem lehet , csak úgy", függvényként hívni (lásd §.2.1. Konverzió független 
típusok között), az operator—-t a másolókonstruktorból szoktuk meghívni. 





Figyeljünk meg két nagyon fontos dolgot! Az egyik, hogy a másolókonstruktor- 
ban le kellett nullázni a data tagváltozót, mert létrejöttekor véletlen értéket 
tartalmaz, míg annak vizsgálatakor az operator- az objektum állapotával kon- 
zisztens értéket feltételez. A másik kérdés a paraméterek típusával kapcsola- 
tos. Figyeljük meg, hogy az operator—ben referenciát adunk-veszünk az argu- 
mentumlistában! Ennek célja nemcsak a gyorsítás, hanem a végtelen ciklus el- 
kerülése is. A másolókonstruktor ugyanis minden egyes érték szerinti paramé- 
terátadáskor meghívódik. Ezért ha a másolókonstruktor az operator—t hívja, és 
az operator—ben van érték szerinti paraméterátadás, akkor az ismét a másoló- 
konstruktort fogja hívni, amely jól láthatóan végtelen ciklushoz vezet. 


a) Útmutató: Az operator: írásakor 
— vizsgáljuk meg, hogy nem ugyanazt a két objektumot kell-e egyenlővé tennünk! 


— ne felejtsük el felszabadítani az értékadás által felülírt pointerek által mutatott te- 
rületeket! 


Az operatorz és a másolókonstruktor összekapcsolása esetén 
— — a másolókonstruktorból hívjuk az operatorz-t! 


— ne felejtsük el inicializálni a másolókonstruktorban az operator- által használt tag- 
változókat! 


— — használjunk referencia szerinti paraméterátadást az operatorz -ben, különben végte- 
ten ciklusba kerülünk! 
LE elksádésatemázzizánásznbamssezhatbsel est a Ze etl za ete s edzel nasi ehe ei 








6.4. Speciális operátorok túlterhelése 


cout cx C-- cc e 
Cout c --C cc e 


nm 





Szintén speciális operátor a zárójel operátor. A függvényhívás, vagy más né- 
ven a zárójel operátort tetszőleges paraméterszámmal meghívhatjuk. Például 
egy mátrix osztály esetén le szeretnénk írni az alábbi kódot: 


Tre 






crix m(2,3); // Egy 2x3-as mátrix létrehozása 
0,0) - 2; // A zárójel operátor 0,0 elem referenciájával tér 

MS //SNAIS SZÁR TÉREN § SATAN OLÉTÜKÜL S NÉL tét 
"cout cc m(0,0); // Itt pedig a konstans referencia is elég 7 











Ehhez az alábbi operátorok megírása szükséges: 





Ismét hangsúlyozzuk, hogy azért van szükségünk nem konstans, elemrefe- 
renciát visszaadó operátorra, hogy meg tudjuk változtatni az egyes elemeket, 
és azért van szükségünk külön konstans operátorra, hogy a konstans gektor- 
nak is le tudjuk kérdezni egy adott indexű elemét. Ha nem double típusú a 
tárolt elem, hanem nagyobb méretű objektum, akkor a konstans operátor 
konstans referenciával is visszatérhet, ami gyorsabb kódot jelent. 
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6. fejezet: Operátorok és túlterhelésük 


Egy mátrix osztály implementálása esetén a zárójel operátor felüldefiniá- 
lása jóval kényelmesebb és hatékonyabb megoldás, mint a kizárólag egy pa- 
raméterrel felüldefiniálható szögletes zárójel operátor. 

Egy paraméterrel indexelhető osztályok esetén (például sztring osztály adott 
karakterének elérése, vektor osztály adott elemének elérése) a szögletes zárójel 
operátor tökéletesen megfelel az indexelt elemhozzáférés megvalósítására. 


RAP 





Az előző példához hasonlóan itt is írtunk egy konstans és egy nem konstans 
referenciával visszatérő operátort. 


6.5. Általános szabályok 


Vannak olyan operátorok, amelyeket nem lehet túlterhelni. Ezek a következők: 
?: :: . .t sizeof typeid 


A fenti listában az első operátor túlterhelése mellett nem hozható fel jó példa, 
a többi operátor pedig vagy , felforgatná" a nyelvet, vagy nehezen érthető 
kódhoz vezetne. 

Természetesen az operátorok kiértékelési szabálya, így a precedencia és 
az asszociativitás nem változtatható meg. Kivétel ez alól a vessző operátor, 
amely alapvetően balról jobbra értékelődik ki, míg ha túlterheljük, a függ- 
vényhívásra jellemző asszociativitással értékelődik ki. Ez azt jelenti, hogy a 
sorrend az adott fordítótól függ. Szintén magától értetődő, hogy új operátoro- 
kat sem hozhatunk létre. A fentiekhez ugyanis meg kellene változtatni a Ctt 
fordítót. Az operátorok túlterhelésénél is igazak a függvények túlterhelésére 
vonatkozó szabályok: az azonos nevű operátorok nem különbözhetnek kizáró- 
lag a visszatérési értékeikben. A túlterhelt operátoroknak nem lehet alapér- 
telmezett típusuk. Bár az öröklésről csak a 7.1. Tagváltozók és tagfüggvények 
öröklése fejezetben lesz szó, a teljesség kedvéért megjegyezzük, hogy az operd- 
tor—-n kívül minden operátor öröklődik. 

Amikor a fordító keresi az operátornak megfelelő tagfüggvényt, az első 
paraméter alapján keres. A Complex példánál láttuk, hogy erre az első para- 
méterre nincs típuskonyerzió: amikor double az első paraméter, hiába biztosít 
a konstruktor double-ről Complexre történő konverziót, meg kellett írnunk 
azokat az operátorokat is, melyek első paramétere double. 


106 








6.6. A pointer-tag operátorok" 


Vannak operátorok, amelyeket csak tagfüggvényként lehet túlterhelni. 
A fontosabbak ezek közül az operator-, az összetett egyenlőség operátorok 
(rz, 7, stb.), valamint [( ], 0, new, delete, new[ ], delete[ ]. 

Végül néhány jó tanács: 


— — S ee. 
Útmutató: Az operátorok túlterhelése nagy segítség lehet, de áttekinthetetlen kódot is 
eredményezhet. Ezért ezzel kapcsolatban érdemes betartani néhány szabályt. 


— — Csak indokolt esetben írjunk túlterhelt operátorokat. A tagfüggvény az esetek nagy 
részében sokkal olvashatóbb. 


— Csak akkor írjunk túlterhelt operátort, ha az természetesen hat, vagyis ha egy adott 
típus esetén egyértelmű, hogy mit csinál. Például egy sztring osztály esetén termé- 
szetes, hogy a kétargumentumú " operátor az összefűzést jelenti, viszont a tr operá- 
tor túlterhelése nem segíti a megértést. 


— — Vigyázzunk azokra az operátorokra, amelyeknek a jelentése eléggé kötött (például 
-2, 44, --). Ha ezekhez új jelentést rendelünk, a kód könnyen áttekinthetetlenné válik. 


— — Ne terheljük túl a vessző operátort, mert teljesen másképp viselkedhet, mint az eredeti. 





6.6. A pointer-tag operátorok" 


A pointer-tag operátorok (pointer-to-member operators) segítségével tag- 
függvényekre is tudunk pointert megadni. Ezt a koncepciót egy példán ke- 
resztül mutatjuk be. 





Feladat: Írjunk egy egyszerű menüt megvalósító programrészletet! Írjunk egy parancsokat 
tartalmazó osztályt, illetve egy menü osztályt, amely meghívja a parancsokat tartalmazó osz- 
tály megfelelő parancsát! 








Ebben a példában néhány egyszerű szerkesztési parancsot implementáltunk: 


class EditCommands 
public: 5 
void CopyO( cout cx "Copy" cc endi; ) 
void PasteO( cout cc "Paste" sc endi; ) 
void UndoO( cout cz "Undo" cs endi; 3 
3 void Redo()í cout cc "Redo" cc endl; ) 
fagyás Og! egyél tztotrakál 


Ezek után nagy a kísértés, hogy minden menüfunkciónak külön osztályt ír- 


junk, és mindegyik osztályból az EditCommands más-más tagfüggvényét hív- 
juk. Például: 
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ma) 

















Ekkor azonban mindig új osztályt kell írnunk minden egyes parancsnak. Sok- 
kal jobb lenne egy olyan megoldás, amely lehetővé tenné, hogy az osztály létre- 
hozásakor , bekonfiguráljuk" a megfelelő függvényre. Ezt a C nyelvben függ- 
vénypointerekkel oldottuk meg. A Ct- esetén viszont ez nem ennyire egyszerű, 
Statikus tagfüggvényeknél természetesen működik a szokásos függvénypoin- 
ter, nem statikus tagfüggvényeknél viszont figyelembe kell vennünk, hogy a 
hívási mechanizmusnak this pointerként át kell adnia az objektumot. Erre a 
problémára egy lehetséges megoldás az alábbi. 


e — Vesszük az objektumra mutató pointert, hiszen erre nem statikus tag- 
függvény esetén mindig szükség van. 


s — Veszünk egy tagfüggvényre, illetve tagváltozóra mutató pointert. Mi- 
vel az objektumra mutató pointer rendelkezésre áll, a tagváltozó ese- 
tén itt elég csak egy eltolást tárolnunk. Ez az eltolás megadja, hogy az 
objektum kezdőcímétől számítva melyik memóriacímen található az 
adott tagváltozó. Tagfüggvény esetén a this pointeren kívül a függ 
vény címére van szükségünk. 


e — Kialakítunk egy operátort, amelynek paraméterei az objektum vagy 
az objektumra mutató pointer, illetve a fenti információt tartalmazó 
másik pointer. Ez az operátor összefésüli a kettőt, és megkapjuk a 
tagváltozót vagy a tagfüggvényt. 


Az objektum, illetve az objektumra mutató pointer nem jelent különösebb 
problémát, eddig is dolgoztunk velük. Hozzunk most létre egy tagra mutató 


pointert az EditCommands Copy tagfüggvényére! Elsőként deklaráljuk a P9- 
intert pPCommand névvel: ve. 


(void CEditconmándsz:t pCómmandy Or 
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6.6. A pointer-tag operátorok? 
Jól látható, hogy az EditCommands osztály tetszőleges tagjára mutató pointer 
típusa az EditCommands::" kifejezéssel adható meg. Második lépésként adjunk 
értéket a pCommandnak, nevezetesen a Copy tagfüggvényhez tartozó eltolást! 


Mivel az eltolás vagy a függvény címe kiszámítható az osztály, illetve a függ- 
vény memóriabeli elhelyezkedéséből, elég az osztályt és a függvény nevét 
megadni a hatókör operátorral elválasztva. Végül hívjuk meg a függvényt a 
pointer-tag operátorok segítségével, amely várakozásunknak megfelelően ve- 
szi az objektumot és a tagra mutató pointert, kiszámítja az adott függvény 
címét, és meghívja azt. 





Mivel a ." operátor alacsonyabb precedenciaszinten van, mint a függvényhí- 
vás, zárójeleznünk kell. Ha az objektum nem változó, hanem pointer formájá- 
ban áll rendelkezésre, akkor a .-2 operátort alkalmazhatjuk a cím kiszámítá- 
sára és a függvény meghívására. 

A pointer-tag változók segítségével hatékonyan oldhatjuk meg az eredeti 
feladatot. Létrehozunk egy olyan osztályt, amely eltárol egy pointert, amely 
az EditCommands void visszatérésű és void paraméterlistát váró tetszőleges 
tagfüggvényére mutathat. Ezt a konstruktorban a kívánt tagfüggvénnyel ini- 
cializáljuk, vagyis tényleg , konfigurálhatjuk" a megfelelő parancsra. Így a 
szerkesztést megvalósító parancsok meghívására elég egy menü osztályt írni. 








43 A bemutatott módszer nagyon hasonlít a .NET alapú programozási nyelvek delegát nevű 
konstrukciójához. Fontos különbség, hogy ott csak a metódus (tagfüggvény) alakját kell 
megadnunk, míg Ct-4-ban az osztály típusa is szükséges az eltolás kiszámításához. A kü- 
lönbség oka, hogy a .NET keretrendszer eltárolja az egyes típusokra vonatkozó informá- 
ciót, és ezeket futási időben le lehet kérdezni. A Ctt futásidejű típusinformációi nem 
ennyire kiterjedtek, viszont cserébe a C-t programok gyorsabban futnak. 


109 














6. fejezet: Operátorok és túlterhelésük 





t 
this-stext — text; 
this-spcommand - pCommand; 
this-spcommands - pCcommands; 
J 


void FireCommand() 
(pcommands-5 tpcommand) O ; 


J 
h 


Az osztályban eltároljuk az EditCommandsra mutató pointert. Figyeljük meg, 
hogy mivel nem az EditMenultem hozta létre, nem is ez felelős a felszabadítá- 
sáért. Sőt, az alábbi példánkban nem is dinamikusan foglaljuk ezeket az ob- 


jektumokat: 


int main 
1 
Editcommands editCommands; 


// ugyanaz az osztály minden menüelemre 

EditMenultem copyíItem("Copy...", €editcommands, 
€EditCcommands : : Copy) ; 

EditMenuItem pasteltem("Paste...", €editCommands , 
€EditCcommands : : Paste) ; 

EditMenuItem undoltem("Undo...", geditcommands, 
€EditcCommands : : indo) ; 

EditMenurItem redortem("Redo...", €editcommands, 
GEditcCommands : : Redo) ; 


// Teszteljük 
copyItem.FireCommandOJ; — // copy 
pastelItem.FirecommandO ;  // Paste 
undortem. Fi recommandO; — // Undo 
redortem, Firecommand(); — // Redo 


A példát egy közös őssel tovább általánosíthatjuk, ugyanis a pointer-tag OPe- 


rátor a virtuális függvényekre is működik. Ezeket a technikákat a következő 
fejezetben tárgyaljuk. 
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HETEDIK FEJEZET 


, e. 


Általánosítás és specializáció 


A 3.1. fejezetben az objektumorientáltság harmadik alapelvét, amely az ,egy- 
fajta" vagy ,az egy" kapcsolatot hivatott implementálni, öröklésnek hívtuk. 
Nézzük meg az alábbi leírásokat, és figyeljük meg, hogy ami elmondható a 
személyről (Person), az elmondható az alkalmazottról (Employee) is: 


A személynek van neve, születési ideje, életkora, személyi száma, állampol- 
gársága. 

Az alkalmazottnak van neve, születési ideje, életkora, személyi száma, ál- 
lampolgársága. 


A személy és az alkalmazott között fennáll az , egyfajta" kapcsolat, hiszen né- 
hány szélsőséges példától eltekintve az alkalmazott személy. Ezt a kapcsola- 
tot a továbbiakban üresháromszög-fejű nyíllal jelöljük. 


JA 


Employee 


10 ábra. Az osztályok közötti egyfajta" kapcsolat jelölése 


A személy és az alkalmazott között lévő egyfajta" kapcsolatnak két követ- 
kezménye van: 

Ha a személynek van egy bizonyos tulajdonsága (neve, személyi száma, 
állampolgársága), akkor az alkalmazott is rendelkezik vele, vagyis örökli eze- 
ket a tulajdonságokat. 

Amit elmondhatunk egy személyről, az minden alkalmazottra igaz. Va- 
gyis, ha a fenti, a személyről szóló szövegrészben a személyt alkalmazottra 
cseréljük, akkor is igaz állításokat kapunk. Ezt nevezzük behelyettesíthető- 
ségnek. A fenti ábrán a nyíl szintén a behelyettesíthetőség irányába mutat. 

A továbbiakban megvizsgáljuk, hogyan támogatja a C-t fenti két jellem- 
zőt, a tulajdonságok öröklését és a behelyettesíthetőséget. 














7. fejezet: Általánosítás és specializáció 


2. TEJEze ts TT e teme 


7.1. Tagváltozók és tagfüggvények öröklése 


e. 
Feladat: Írjunk olyan programrészletet, amely egy munkaadói nyilvántartás részeként képes 
személyek adatait tárolni (név, születési év) az alkalmazottak adataival együtt (név, születési 
év, munkába állás éve). Ettől a prototípustól mindössze annyit várunk el, hogy kiírja egy sze- 
mély vagy egy alkalmazott adatait a szabványos kimenetre. 





A megoldás első lépéseként tekintsük az alábbi osztályokat! 


include cstringz 7 
finclude ciostreams 
using namespace s 








teege ille ES átalatés 
class Person 
























( 
String name; 7 
int birthYear; 
public: sz ő 
Person(stri ame (name) , 
void Prin sc birthYear cc endi; ) 


void SetBirth hiszsbirthvear - birthvear; . 





A Person osztály definíciója nem szorul magyarázatra. Az Employee osztály 
definíciójánál látható, hogy az öröklést úgy adjuk meg, hogy a leszármazott 
osztály neve után kettőspontot teszünk, majd megadjuk az öröklés láthatósá- 
gát és azt az osztályt, amelytől örökölni szeretnénk. Azt az osztályt, amelyből 
leszármaztatunk, ősosztálynak (ancestor class) vagy áluposátályaak (base 
class) nevezzük. Azt az osztályt pedig, amely örököl egy másik osztályból, le- 
származott osztálynak (derived class) hívjuk. Az öröklés (inheritance), 
amelyet származtatásnak is neveznek, azt jelenti hogy a leszármazott OSZ- 
tályban megjelennek az ősosztály tagváltozói és tagfüggvén. ei. Mivel az örök- 
lés láthatósága publikus, a példánkban ezekhez hozzá 15 eüdlks férni. Az 
Employee osztályban szintén megjelenik a SetBirthYear függvény: í 
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7.1. Tagváltozók és tagfüggvények öröklése 


Egyelőre tegyük fel, hogy az Employee osztály rendelkezik a megfelelő konst- 
ruktorral, amelyet később fogunk megírni. Ez a konstruktor majd beállítja a 
nevet, a születési évet és a munkába állás évét. Az ősosztály tagváltozói fizikai- 
lag is megjelennek a leszármazott osztályban. A fenti példában létrehozott e 
nevű, Employee típusú objektum memóriaképe két részből áll: az egyiket a 
Person osztály tagváltozói (name, birthYear) alkotják, a másik rész a saját tag- 
változóit tartalmazza (ilyenből jelen esetben csak egy van: employment Year). 


Employee e; 





Person 
birthYear 


employmentYear 






Employee 


11. ábra. Employee objektumok memóriaképe 


Miután kiegészítettük az Employee osztályt a munkába állás évét tároló tag- 
változóval és az azt beállító függvénnyel, ki kell írnunk az összes adatot a 
szabványos kimenetre. Az első kérdés, hogy nevezhetjük-e ezt a függvényt 
Print függvénynek. A probléma az lehet, hogy van már egy Print függvé- 
nyünk, amit a Person osztályból örököltünk, és az is pontosan ilyen argumen- 
tumlistájú, vagyis eddigi ismereteink szerint a függvénynév-túlterhelés ér- 
telmében (2.2. Függvénynevek túlterhelése fejezet) ez nem megengedett. Örök- 
lés esetén azonban ez nem probléma, mert a fordító különbséget tud tenni a 
két függvény között. Tehát a leszármazott örökli ugyan a szülő összes műve- 
letét, vagyis esetünkben a Print függvényt is, de ha annak működése nem fe- 
lel meg számunkra, lehetőségünk van módosítani, azaz ugyanolyan néven új 
törzset megadni neki. Vagyis bátran leírhatjuk az alábbi kódot: 





Viszont felmerül a kérdés, hogy ha leírjuk az alábbi kódot, "melyik Print függ- 
vény fog meghívódni. A Person:: Print vagy az Employee::Print? 
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Ebben a kérdésben az egységbe zárás már jól ismert alapelve igazít el minket. 
Mivel Employee típusú objektummal van dolgunk, a fenti kódrészletben az 
Employee::Print() hívódik meg." 

Az Employee::Print függvény feladata annyi, hogy kiírja az alkalmazott 
nevét, születési évét és a munkába állás időpontját. Ám olyan függvényünk 
már van, amely kiírja az első két adatot: a Person::Print(). Első kísérletként 
vizsgáljuk meg az alábbi kódrészletet: 





A kísérletben szerettük volna meghívni az ősosztály Print függvényét. Vi- 
szont — mivel az Employee osztály egyik tagfüggvényét írjuk —, az egységbe 
zárás értelmében az Employee osztály Print függvénye hívódik meg, csakúgy, 
mint az előző alkalommal. Vagyis a fenti programrészlet végtelen rekurziót 
eredményez. Meg kell mondanunk, hogy a Person osztály Print függvényét 
szeretnénk meghívni, amire a már jól ismert hatókör operátort használjuk: 


(7 vojd PPIMEOK Persont:PriNtO; coút ee employmentvear cc endiib 


Végül az Employee osztály inicializálását kell megoldanunk. A konstruktorok 
az öröklés szempontjából sem úgy viselkednek, mint a többi függvény. Termé- 
szetesen az ősosztály konstruktora is megjelenik a leszármazott osztályban, 
de ott már nem úgy viselkedik, mint egy konstruktor. Az ősosztály konstruk- 
torát csak a leszármazott konstruktora hívhatja. 

Példánkban az Employee osztály inicializálásához három adatra van szük- 
ségünk: a névre, a születési évre és a munkába állás évére. Vagyis az Employee 
osztály konstruktorának ez a három argumentuma lesz. Az egységbe zárás ne- 
vében viszont szeretnénk, ha az Employee osztály Person részének inicializálá- 
sát a Person osztály konstruktora végezné. 





u. Itt jegyezzük meg, hogy ha a leszármazott osztályban van egy azonos nevű függvény (a pa- 
raméterlista itt most nem számít), akkor az elrejti az alaposztály ugyanolyan nevű függvé- 
nyét, így a leszármazott osztály objektumaira a tagfüggvény nem hívható. Ezt névelrej- 
tésnek (name hiding) nevezzük. Ezért előfordulhat, hogy az ősosztályban van egy megfelelő 


mérlegeltük És 
helyeznünk az Employee osztályban. Ez azonban elég ritka szándék. 
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7.1. Tagváltozók és tagfüggvények öröklése 





Az ősosztály konstruktorát a fenti szintaxissal hívhatjuk: a konstruktor fejléce 
után kettőspontot írunk, majd az ősosztály konstruktorának neve és az át- 
adandó argumentumok következnek. Ha több ősosztály van, és így több konst- 
ruktort is szeretnénk meghívni, akkor a konstruktorhívásokat vesszővel vá- 
lasztjuk el egymástól. Így a konstruktor törzsében csak az Employee osztály sa- 
ját adattagját, vagyis a munkába állás évét kell inicializálni. Ez a megoldás hí- 
ven tükrözi az egységbezárás alapelvét: a leszármazott osztályban az ősosz- 
tályból származó részt az ősosztály konstruktora inicializálja, a leszármazott- 
ban hozzáadott adattagokról pedig a leszármazott konstruktora gondoskodik. 

Megjegyezzük, hogy ha nem hívtuk volna meg a Person osztály konst- 
ruktorát, fordítási hibát kaptunk volna. Ha ugyanis nem hívjuk meg explici- 
ten az ősosztály adott konstruktorát, automatikusan a paraméter nélküli, 
alapértelmezett konstruktora hívódik meg, amellyel a Person osztály nem 
rendelkezik. Vagyis, ha az ősosztály alapértelmezett konstruktorát szeret- 
nénk meghívni, azt nem kell külön jelezni a konstruktor inicializálási listájá- 
ban. Vegyük észre, hogy az ősosztály részének inicializálásakor a típus szere- 
pel a konstruktor inicializálási listájában, tagváltozók inicializálása esetén 
(lásd 3.7. Tagváltozók inicializálása fejezet) pedig a tagváltozó neve: 


be 





A feladat teljes megoldását az alábbi kódrészlet összegzi: 
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Végül a láthatóság és az öröklés kapcsolatát vizsgáljuk meg. A fenti kódban a 
kiíratás a sortörések miatt nem túl elegáns, hiszen az első két adat után sor- 
törés következik: 


Ha viszont az ősosztályból kivesszük a sortörést, a Person osztály önmagában 


nem fogja megállni a helyét. Ezért teszünk egy kísérletet az Employee::Print 
függvény átírására: 











7.A. Tagváltozók és tagfüggvények öröklése 


kulcsszóra lenne szükség, amely kívülről továbbra sem enged hozzáférést a 
bírthYear tagváltozóhoz, vagyis nagyon hasonlít a privátra, de az öröklés irá- 
nyában nem olyan szigorú: a tagfüggvénye számára hozzá- 


férhetőek az így megjelölt tagok. Ez a kulcsszó a protected. Ha változó, il- 
letve egy tagfüggvény protected, akkor csak az adott osztály iröntók leszár- 
mazottai férhetnek hozzá. Így a Person osztály módosításával már le fog for- 
dulni az új Employee::Print függvényünk. 





A fenti megállapítások csak akkor igazak, amikor az öröklés megadásánál az 
ősosztály neve előtt a public kulcsszót használjuk. Ha ugyanis private vagy 
protected öröklést adunk meg, akkor szigorúbbá lehet tenni az ősosztályban 
megadott hozzáférést. A láthatóságot az alábbi táblázat foglalja össze. 





A táblázat első oszlopában az öröklés láthatósága található. A táblázat fejléce 
az ősosztálybeli hozzáférést jelenti. Előző példánkban az öröklés publikus 
volt, vagyis a táblázat első sora vonatkozik rá. Ez esetben, ha egy tagváltozó 
vagy egy tagfüggvény publikus volt a Person osztályban, az Employee tag- 
függvényei, más osztályok tagfüggvényei és a globális függvények úgy férhet- 
nek hozzá, mintha publikusként lett volna deklarálva az Employee osztály- 
ban. A táblázat utolsó oszlopa arról árulkodik, hogy a privát tagváltozókhoz 
semmilyen öröklés esetén nem férhetünk hozzá. Érdemes megfigyelnünk, 
hogy a táblázat első sorának elemeihez képest az alattuk lévők sosem enge- 
dékenyebbek, sőt, egyre szigorúbbak. Ez azt jelenti, hogy az öröklés látható- 
ságával sohasem lehet enyhíteni az eredeti hozzáférést, csak szigorítani. 


s EDE ta IŐATMÍTALÁLRON VT BE ZEES E SE SSE SES e 
Útmutató: Szinte mindig publikus öröklést használunk: ebben az esetben a privát tagokhoz 
nem lehet hozzáférni, a többi tag láthatósága pedig ugyanolyan, mint az ősosztályban. Az úgy- 
nevezett korlátozó öröklés (lásd a következő részt) esetén privát öröklést használunk, a 


protected öröklést pedig szinte sohasem használjuk. 
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7. fejezet: Általánosítás és specializáció 


7.2. Behelyettesíthetőség 


Időzzünk még egy kicsit a személy-alkalmazott példánál! Próbáljunk meg vál- 
tozókon, illetve pointereken keresztül hozzáférni az objektumokhoz! Elsőként 
nézzük meg az alábbi objektumokat: 


Person person("Garfield" 1 19699. 







Employee Ötaá zás KEtjő 1964, te 
person. SetEmploymentvear(1980);  // Nincs ilyen tagfüggvény 





lta , örökli a Persontól 
 meghívódik a Person: :Print 


enployee.SetBirehvearC 
meghívódik az Employee::Print 


person.PrintO; / 
employee.PrintO;  / 


A fenti példákban nincs semmi meglepő. A tagfüggvényekhez objektumválto- 
zókon keresztül férünk, így a változó típusa meghatároz egy tagfüggvényt, és 
az hívódik meg. Ha az adott osztálynak nincs olyan tagfüggvénye, akkor for- 
dítási hibát kapunk. 

A pointerek esetén nem mindig ilyen egyértelmű a helyzet. A pointeren 
keresztül végrehajtott műveletek esetén ugyanis két típus is szerepet játszik: 
a pointer típusa és a mutatott területen található változó típusa. Amikor ez a 
kettő egybeesik, akkor ugyanolyan egyértelmű a helyzet, mint a változón ke- 
resztül végrehajtott műveletek esetén. Amikor pedig különbözik, a művelete- 
ket a pointer típusa határozza meg. Vegyünk egy egyszerű C nyelvű példát, 
amely kiírja egy 32 bites int típusú változó memóriabeli reprezentációját (eb- 
ből például megtudjuk, hogy az adott processzorarchitektúra milyen sorrend- 
ben helyezi el az int típus egyes bájtjait a memóriában)! 


dat: tutögef s OXEFEFADÓSI 


Keneek 





Ebben a példában a mutatott területen található változó típusa int volt, a poin- 
ter típusa unsigned char. A műveleteket a pointer típusa határozza meg. 
A ptrli) kifejezést a "(ptrtitsizeof(unsigned char)) képlet szerint számolta a for- 
dító, vagyis a pointeren végzett műveleteket csak a pointer típusa befolyásolja. 
A fenti példában a különbség szándékos volt, de ez akár hibához is vezethet. 
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7.2. Behelyettesíthetőség 





Mivel a double és a char változóknak teljesen más a memóriabeli reprezentá- 
ciójuk, ha úgy akarunk megnövelni egy double típusú változót, mintha char 
típusú lenne, furcsa eredményhez jutunk. Ez az eredmény nem ugyanaz min- 
den platformon, de mindenhol hasonlóan értelmetlen. Ebből a szempontból a 
double és a char inkompatibilis típusok. 

Térjünk most vissza az eredeti példánkhoz, és mutassunk rá egy 
Employee típusú objektumra egy Person típusú pointerrel! 





Tanulmányozzuk a két típus memóriareprezentációját, hogy eldönthessük, 
kompatibilis típusokról van-e szó! 





Person" pPerson  Employee e; Person person; 
é 
59 L Employee —ere] [19 


12. ábra. Person és Employee objektumok memóriaképé 


Az ábrán jól látható, hogy az Employee típusú objektum eleje megegyezik egy 
Person típusú objektummal, és a pPerson pointer valóban az Employee objek- 
tum Person típusú részére mutat. A pointeren keresztüli hozzáférés szem- 
pontjából az Employee osztály kompatibilis a Person osztállyal. Ez általában 
is igaz: ha egy osztály csak egy osztályból örököl, akkor mindig kompatibilis 
az ősosztállyal. Ezt a kompatibilitást szinte mindegyik fordító a bemutatott 
memóriareprezentáció kialakításával támogatja: mindig a leszármazott osz- 
tály elejére helyezi el az ősosztály tagváltozóit. 

A fejezet bevezető példáin keresztül láttuk, hogy az elvégzendő műveleteket 
a pointer típusa határozza meg. Természetesen a pPerson pointer nem tudja, 
hogy az általa mutatott Person típusú rész még folytatódik, és egy Employee tí- 
pusú objektummá egészül ki. Ezért a pPerson pointeren keresztül nem is lehet 
elérni az Employee típusú objektum további részét. Vagyis a 





programsor teljesen hibás, hiszen a Person osztálynak továbbra sincs set- 
EmploymentYear tagfüggvénye. A másik érdekes kérdés, hogy melyik Print 
függvény hívódik meg, ha leírjuk a 


MG EZBJHE KEST EBA TBAKO SZT EH T VAKEOA MEZGTS TAI SBITSZNÖKTESÉSS SÉBRNAONMÉNZRKTNTTÉ 


kifejezést. A válasz az eddigiekből egyenesen következik. Mivel a műveletet a 
pointer típusa határozza meg, és nem a mutatott memóriaterületen elhelyez- 
kedő objektum típusa, a Person::Print függvény fog meghívódni, vagyis csak 
két adat fog kiíródni a szabványos kimenetre, 
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7. fejezet: Általánosítás és specializáció 


Ha az eddigiekhez hozzávesszük, hogy mindez nemcsak pointerre, hanem 
referenciára is igaz, kimondhatjuk a behelyettesíthetőség C--t-beli megvalósí. 
tásának lényegét: 

Egy ősosztály típusú pointernek mindig értékül adhatunk egy le- 
származott típusú pointert vagy egy leszármazott típusú objektum 
címét. Referencia esetén ez azt jelenti, hogy egy ősosztály típusú re- 
ferenciát inicializálhatunk leszármazott típusú objektummal is.45 Az 
ősosztály típusú pointeren, illetve referencián keresztül csak az ős- 
osztálybeli tagváltozók, illetve tagfüggvények érhetők el.16 

Ennek közvetlen következménye, hogy ha van egy Person típusú mutatónk, 
az nemcsak egy Person típusú adatterületre mutathat, hanem a Person osztály 
tetszőleges leszármazottjának objektumpéldányára. Vagyis sohasem lehetünk 
biztosak abban, hogy mi , rejtőzik" egy Person típusú mutató mögött: Employee 
vagy Person típusú objektum. Azt a jelenséget, hogy az ősosztály típusú poin- 
ter mutathat bármelyik leszármazott típus példányára is, polimorfizmus- 
nak nevezzük, a mutatót pedig polimorfnak.7 A polimorfizmus görög erede- 
tű szó, magyarul többalakúságot jelent. C-tHt-ban polimorfizmus csak pointe- 
ren vagy referencián keresztül lehetséges. A C-t tehát a pointer egyik leg- 
gyakoribb C nyelvű használatát, a cím szerinti paraméterátadást a referen- 
ciatípus segítségével feleslegessé tette, viszont egy új funkciót rendelt hozzá: 
a polimorfizmust legtöbbször pointeren keresztül használjuk."§ A további le- 
hetőségek bemutatására egy új esettanulmányt választunk. 


Pét TÉES Ézt — EZE LEE ntkdé ral ez eb tel EZ Sr kola JEA s ÖM ee 
Feladat: Egy matematikai program részeként köröket és téglalapokat szeretnénk egy tömb- 
ben nyilvántartani. A kör és a téglalap legyen képes kiszámolni a saját területét! A hibakere- 
sést megkönnyítendő definiáljunk egy Print függvényt, amely kiírja, hogy téglalapról vagy kör- 
ről van szó. 

felntknásztétazszádtaklkáe seszstse e zzzztétnó Éld ése a Me sze erzo dlrlőllálsláe akin et 





45 Referencia esetén csak inicializáláskor élhetünk ezzel a lehetőséggel, hiszen az inicializá- 
lás után a referencia teljesen úgy viselkedik, mint egy változó. Ha értékadáskor is ki sze- 
retnénk használni a behelyettesíthetőséget, akkor Pointert kell alkalmaznunk. 
Nyelvi szinten ez azt jelenti, hogy ha leszármazott osztály típusú pointert ősosztály típusú 
RA sk Ek ati tsa a típuskonyerzió automatikus. Referencia esetén ez csak ini- 
fé; egyébként az obj. z k EGG típuskon- 
verziókat a következő, 8. fejezet lzeltes KESESÉB CEGSZ ZT 
" Vannak, akik a függvénynév túlterhelését is polimorfizmusnak hívják, hiszen ugyanaz a 


migyélőt Többi flakban is megjelenik. Ebben a könyvben ezt az esetet nem tekintjük poli- 





Eeezszetsmeössszetetsz a sze sss ÉRÁK ÉeÁYNNÉl elb 


Az eddigiek alapján a téglalap és a kör megírása nem jelenthet problémát: 





A kérdés az, hogy milyen típusú legyen az a tömb, amelybe el tudunk tárolni 
kör és téglalap típusú elemeket is. A megoldásban a behelyettesíthetőség lesz a 
segítségünkre. Ha a lenne egy közös ősosztály, akkor a tömb ősosztály típusú 
pointereket tárolna, hiszen a behelyettesíthetőség miatt az ősosztály típusú po- 
intereknek bármikor értékül adhatunk leszármazott osztályra mutató pointe- 
reket. De mi legyen az ősosztály neve? Ez gyakran előforduló probléma: érez- 
zük, hogy szükségünk van egy ősosztályra, de nem tudunk rögtön nevet találni 
neki. Itt ugyanis az objektumorientált szemlélet megköveteli tőlünk, hogy a név 
elégítse ki az , egyfajta" kapcsolatot. Jelen példánkban mi az alakzat (Shape) 
elnevezés mellett döntöttünk. A téglalap, illetve a kör is egyfajta alakzat, tehát 
az elnevezés tükrözi és indokolja az örökléssel történő implementációt. 





Útmutató: Amikor egy közös ősosztályra van szükségünk, körültekintően válasszuk meg a ne- 
vét, figyelve arra, hogy az ,egyfajta" kapcsolat fennálljon! Néha nagyon nehéz találó nevet 
adni az ősosztálynak, de megéri a fáradságot, hiszen nagyban megnöveli a kód érthetőségét. 

uisálablöátaloekárászázátt Áá nin árasztott. slakelbntkl se sz 20 [dort es lordht skan] zárat siker mee bes mlétzász est es [/ 
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A három osztály felhasználásával most már el tudjuk tárolni ezeket az osztá- 
lyokat egy közös tömbben: 





Emlékeztetünk rá, hogy polimorfizmus csak pointeren vagy referencián ke- 
resztül lehetséges, így a tömbnek ősosztály típusú pointereket kell tartal- 
maznia. A kialakult memóriakép a következő: 


Shape" shapes[10]; 


A 








hogy ,Shape". Ez nem meglepő, hiszen a pointer tlrüsá határozza 
melyik Print függvény hívódjon meg, és a pointer típusa jelen Eszre zott d 
Természetesen ez nem felel meg céljainknak. í 
Az első gondolatunk az lehetne, hogy konvertáljuk a shapesl[i] poi 
Circle vagy Rectangle típusra. Ez a jelenlegi egyszerű költureréük eététnés 
lehetséges is volna, de ha mondjuk felhasználói adatbevitel vagy egy állomány 
alapján töltjük fel a tömböt, nem tudhatjuk, melyik típus rejtőzik a polimorf 
shapes[i] pointer mögött. Ha pedig elrontjuk a típuskonverziót, és a shapesfij 
pointer éppen egy Circle típusú objektumra mutat, és mi ahhoz egy Rectangle 
típusú pointeren férünk hozzá, akkor komoly futásidejű hibák elé nézünk, hi- 
szen a Circle és a Rectangle nem kompatibilis típusok, mint ahogy a char és a 
double sem volt az a bevezető példánkban. A probléma abban rejlik, hogy a C-t 
aránylag szigorú típusrendszerét az öröklés mentén , felpuhítottuk", így a poli- 
morf mutató miatt most nem ismerjük a mutatott objektum pontos típusát. 





Útmutató: Ősosztály típusú objektumra mutató pointert konvertálni leszármazott típusú po- 
interré mindig nagyon veszélyes művelet, ha lehet, kerüljük el. Ha mindenképp meg kell ten- 
nünk, körültekintően járjunk el: gyöződjünk meg róla, hogy a polimorf pointer mögött tényleg 
olyan típusú objektum található, amilyenre konvertálni szeretnénk. 


Ezért nem marad más hátra, a Shape" pointeren keresztül kell dolgoznunk. 
Azt szeretnénk elérni, hogy ha egy Shape" pointer mögött valamelyik leszár- 
mazott található, ne a Shape Print tagfüggvénye hívódjon meg, hanem a le- 
származotté. Egészen pontosan ezt írja elő a virtual kulcsszó, melynek alkal- 
mazásával az egyes tagfüggvények virtuálissá tehetők: 





A virtuális függvény (virtual function) azt jelenti, hogyha 


e — az ősosztályban virtuálisnak deklarálunk egy tagfüggvényt, és 


e a leszármazott osztályban létezik egy ugyanolyan nevű, argu- 
mentumlistájú és visszatérési értékű függvény, továbbá 


s ezt a függvényt egy leszármazott osztályra mutató, ősosztály 
típusú pointeren/referencián keresztül hívjuk meg, 


akkor a leszármazottbeli tagfüggvény fog meghívódni. 
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7. fejezet: Általánosítás és specializáció 
A virtual kulcsszót értelemszerűen csak nem statikus tagfüggvényekre alkal- 
mazhatjuk. Ha a leszármazott osztályban írunk egy ugyanolyan nevű, argu- 
mentumú és visszatérési értékű függvényt, mint az ősosztály egy virtuális 
függvénye, akkor az ősosztály függvényét felülírjuk (override). Figyeljük meg a 
virtuális függvény működésének feltételeit! Fontos, hogy a függvényt az ősosz- 
tály típusú pointeren, illetve referencián keresztül kell hívni, és csak akkor van 
értelme, ha a mutatott objektum leszármazott típusú. Vagyis objektumon ke- 
resztüli függvényhívás esetén, vagy amikor a pointer típusa megegyezik az ál- 
tala mutatott objektum típusával, akkor a virtuális függvényeknek nincs jelen- 
tősége. Egy nehezebben észrevehető speciális esetre nemsokára visszatérünk. 
A virtual kulcsszó kiírásával programunk a kívánt végeredményt adja. 
A területszámítást is letesztelhetjük: 





A kóddal azonban nem lehetünk maradéktalanul elégedettek. A Shape osz- 
tály ugyanis annyira általános, hogy nem tudunk számára területszámítást 
írni. Annak ellenére, hogy nem tudunk értelmes kódot beleírni, a függvény: 
nek ott kell lennie a Shape osztályban, mert azon keresztül hívjuk a leszár- 
mazottak függvényeit. Az objektumorientált áttekinthetőséggel viszont egyál- 
talán nincs összhangban, hogy értelmetlen kódrészletekkel nehezítsük a meg- 
értést. Az ilyen helyzetek megoldására szolgál a tisztán virtuális függvény 
(pure virtual function), amelyet az alábbi módon deklarálunk: 





Vagyis ilyenkor a függvénytörzs helyett -0-t írunk. Ezzel azt jelezzük a fordí- 
tónak, hogy az adott osztályban a függvénynek nem kívánunk törzset megad- 
ni, csak majd a leszármazott osztályokban. Ha azonban ezek után a Shape 
osztályt példányosítanánk, és meghívnánk a Shape::Area tagfüggvényt, a for- 
dító bajban lenne, hiszen nem adtunk meg törzset a függvénynek. Így a Shape 
osztályt nem lehet példányosítani: 
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Az, hogy Shape objektumokat nem lehet létrehozni, 

problémát. A Shape osztályt ugyanis csak arra kaszt Kezkákezökse 
tatókat, pontosabban mutatók tömbjét hozzuk létre, és ezen mutatókon ke- 
resztül hívjuk a Rectangle vagy a Circle Area tagfüggvényét. 

A legalább egy tisztán virtuális függvényt tartalmazó osztályt absztrakt 
osztálynak (abstract class) nevezzük. Az absztrakt osztályokat, mint láttuk, 
nem lehet példányosítani. 4 

A másik csinosítás, amit végezhetünk a kódon, hogy tagfüggvény írja ki a 
területet is. Az első lehetőség az lenne, hogy mind a Rectangle, mind a Circle 
osztályban írnánk egy PrintArea függvényt az alábbi módon: 





Ugyanazon kódrészlet többszöri megjelenése viszont egyáltalán nem elegáns, 
függvény esetében pedig egyenesen elítélendő. Ennek egyik legfőbb oka, hogy 
ha valami hiba van benne, és az egyik előfordulását kijavítjuk, a másikat 
nagy valószínűséggel elfelejtjük módosítani. Másrészt az egységbezárás alap- 
elve is ez ellen szól: ha minden alakzatnak ki kell írni a területét ugyanazzal 
a kódrészlettel, akkor miért nem a Shape objektumban tesszük mindezt? 


e — ——— 
Útmutató: Egy adott funkcionalitást, kódrészletet, tagfüggvényt, tagváltozót mindig a lehe- 
tő legáltalánosabb osztályba tegyünk az osztályhierarchiában! Kerüljük el ugyanazon kód több- 
szöri megjelenését, akár olyan áron is, hogy új ősosztályt vezetünk be! 


Ezért azt a megoldást választjuk, hogy a Shape::PrintArea függvényét módo- 
sítjuk úgy, hogy írja ki a területet, és a Shape::PrintArea függvényt meghív- 
juk a leszármazottakból. 


























7. fejezet: Áltatánosítás és specializáció 


E. TEJELET ÉN e etetett mááá 





Egy ilyen rövid kódrészletnél a függvényhívás majdnem ugyanannyi helyet 
tölt ki, mint a kód, ugyanakkor a példa jól illusztrálja azt az alapelvet, amely 
hosszabb kódrészletek esetén nagyságrendekkel áttekinthetőbbé teszi a prog- 
ramot, és lehetővé teszi az ősosztály kódjának újrafelhasználását. 

A megoldás másik érdekessége a Shape::PrintArea függvényben rejlik. 
A fenti program kimenetén jól látható, hogy a Shape::PrintArea függvény ál- 
tal meghívott Area a megfelelő leszármazottak területszámító függvénye. 





Az alábbi kódrészletben látszólag nem teljesül az a feltétel, hogy egy ősosztály 
típusú, de leszármazott típusú objektumra mutató pointeren keresztül hívódik 
a függvény, hiszen a Shape osztály PrintArea tagfüggvényéről van szó: 


A színfalak mögött viszont pontosan ez a helyzet. Emlékezzünk vissza a 3.2.2. 
Tagfüggvények fejezetre, ahol a tagfüggvények hívását elemeztük. A tagfügg- 
vény első, láthatatlan paramétere egy this pointer. Amikor leírjuk a 


kifejezést, akkor a shapes[(i] mögött vagy egy Circle, vagy egy Rectangle típu- 
sú osztály található, mert a Shape absztrakt. A this pointer a shapes[ij lesz, 
így a Shape::PrintArea-beli this-3Area() hívás (ahol a this pointert az egysze- 
rűség kedvéért nem írjuk ki, de a fordító így értelmezi) egy Shape típusú, de 
vagy Circle, vagy Rectangle típusú objektumra mutató pointer. Vagyis telje- 
sen jogos, hogy itt a this mutatón keresztül ugyanúg; nyes ir 
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7.2. Behelyettesíthetőség 


Fogalmilag egyértelmű a négyzet helye, hiszen a négyzet egyfajta téglalap, 
amelynek oldalai egyenlők. Ha az implementáció szempontjából közelítjük 
meg a feladatot, felmerül a kísértés, hogy a téglalap és az alakzat közé he- 
lyezzük el. Ez azért kényelmes, mert a négyzetnek van egy a oldala és az azt 
kezelő tagfüggvények, a téglalap pedig örökli mindezt, és hozzátesz egy b ol- 
dalt, valamint a hozzá tartozó tagfüggvényeket. Ezt a csapdát érdemes elke- 
rülnünk, ugyanis nem igaz, hogy a téglalap négyzet, viszont a kódunk így ke- 
zeli. A jövőbeni fejlesztések esetén bármikor jöhet egy egyenlő oldalú alakza- 
tokra jellemző funkció, amit majd nem tudunk felülírni a téglalapban, hiszen 
az rá nem vonatkozik, és valószínűleg értelmetlen eredményt is ad. Ezért kö- 
vetjük eddigi vezérfonalunkat, és a négyzetet a téglalapból származtatjuk. 
Viszont van egy feltételünk: az egyenlő oldalú tulajdonság. Ezt a megkötést 
be kell tartatnunk a Sguare osztályban. Ezt úgy tehetjük meg, hogy 





. — a konstruktorban csak egy oldal paraméterét vesszük át, és azt adjuk 
át a és b helyén a Rectangle konstruktorának, valamint 


e írunk egy Sguare::Seta függvényt, amely a Rectangle::Seta és a Rec- 
tangle::Setb függvényeket felhasználva az örökölt Rectangle::a és a 
Rectangle::b változókat ugyanarra a megadott értékre állítja. 


Ez a megoldás ígéretes, de ha valaki meghívja az örökölt Rectangle::Setb 
függvényt, elronthatja az objektum konzisztenciáját: 





El kell érnünk, hogy a publikus Rectangle::Setb-hez ne lehessen kívülről hoz- 
záférni. Az előző rész láthatósággal foglalkozó táblázata alapján ezt a privát 
örökléssel érhetjük el. Ekkor ugyanis minden nem privát tagváltozó és tag- 
függvény úgy lesz hozzáférhető, mintha a Sguare osztályban privátnak dekla- 
ráltuk volna: a Rectangle publikus tagjai, beleértve a Setb tagfüggvényt, a 
Sguare esetében kívülről, más osztályok, valamint a többi osztály tagfüggvé- 
nyei számára nem lesznek elérhetők. Így a megoldás a következő: 
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7. fejezet: Általánosítás és specializáció 

A példában a téglalap funkcionalitását a leszármazottban korlátoztuk, az 
ilyen jellegű öröklést korlátozó öröklésnek (restriction) hívjuk. C-t-ban ezt 
privát (esetleg protected) örökléssel implementálhatjuk.19 Kibővítve a tesztet; 





A futtatás eredménye az alábbi: 





A futtatás eredménye az lett, amit vártunk. A Sguare::Print hívódott meg, 
annak ellenére, hogy a Rectangle::Print tagfüggvény deklarációjában nem 
használtuk a virtual kulcsszót. Az erre vonatkozó szabály az, hogy ha egy 
függvényt virtuálisnak deklaráltunk, akkor az olyan hatású, mintha az ösz 
szes, a leszármazottakban felülíró függvényt is virtuálisnak deklaráltuk volna. 
Ezt úgy is szokták mondani, hogy a C--t-ban (nemcsak korlátozó öröklés esé 





"9 A privát öröklés használatát kétféleképpen közelíthetjük meg. A C-t programozók né 
tekintik egyfajta" (is-a) kapcsolatnak, hanem a , segítségével implementáljuk" (imple 
mented in terms of) kapcsolat megvalósításának tartják, amely a tervezés során EE 
jelenik meg, mindössze egy implementációs megoldás. Például a kört az ellipszis " 
gével implementáljuk. Ebben az elképzelésben az ellipszis osztálynak csak az imitt" 
tációját örököltük, kívülről látható interfészét (publikus tagfüggvényeit) nem, 
-ősosztály publikus tagfüggvényei nem publikusak a leszármazottban, vagyis nem 
leszármazott külső terfészének. Viszont amikor csak az implementációra 

günk, ajá b ére : felhasználhat 7; 1 tjuk a másik osztályt. Ez sokkal 

Ha az objektumorientált szemlélet , egyfajta" kapcsolata szerint közelítjük meg 


















7.2. Behelyettesíthetőség 





tén) nem lehet megszakítani a virtuális láncot,0 vagyis azok a függvények, 
amelyek a leszármazottakban felülírnak, automatikusan virtuálisak lesznek. 
Ennek magyarázatát a virtuális függvény implementációjával foglalkozó 
részben (7.3. fejezet) találhatjuk meg. A másik figyelemre méltó dolog, hogy 
privát öröklés esetén szükséges a típuskonverzió: 


A nyelv ugyanis megpróbál megvédeni minket attól, hogy a korlátozó öröklés 
megkötéseit az ősosztályra történő konverzió segítségével véletlenül megke- 
rüljük. Ha ugyanis lenne automatikus típuskonverzió Rectangle"-ra, akkor 
Rectanglet-mutatón keresztül meghívhatnánk a Setb függvényt. Éppen ez az, 
amit el szerettük volna kerülni. Viszont a Shape annyira általános (azon a 
szinten nem elérhető a Setb függvény), hogy azon a szinten nem szeghetjük 
meg a megkötéseket, így nyugodt szívvel erőltethetjük a fordítónak ezt a tí- 
puskonverziót.! 

Habár a feladatot ezzel megoldottuk, a Sguare::Area csak az ősosztály tí- 
pusú pointereken keresztül hozzáférhető, vagyis az alábbi kód hibát ad: 





Ezt egy csomagolófüggvénnyel meg lehet oldani: egy publikus függvényt dek- 
larálunk a Sguare osztályban, amely visszaadja a Rectangle::Area eredmé- 
nyét, mintegy becsomagolva az ősosztály függvényét: 





Erre azonban egyszerűbb lehetőségünk is van: meg kell említenünk az osztály 
publikus részében azoknak a tagoknak a nevét (függvények esetén nem kell 
paraméterlista), amelyeket publikussá kívánunk tenni: 








50 A .NET keretrendszer nyelveiben a virtuális lánc megszakítható, Cit-ban például a new 


kulcsszó segítségével. 
51. C4-4 programozás szempontjából elegánsabb lenne a reinterpret. cast alkalmazása, azt azon- 


ban csak a 8.3. A C44 típuskonverziós operátorai fejezet tárgyalja. 
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7. fejezet: Általánosítás és specializáció 





Tekintsük most újra együtt a területszámító programot! A fenti megoldások 
előnye az érthetőség és a könnyű kiterjeszthetőség. Amennyiben be szeretnénk 
vezetni egy háromszöget reprezentáló osztályt, a fenti osztályok közül egyet 
sem kell megváltoztatni, a bennük implementált funkciókat viszont a három. 
szög osztály is könnyen felhasználhatja. Az újonnan bevezetett Triangle osztá. 
lyunk is automatikusan tagja lehet a Shape? típusú tömbünknek, amennyiben 
Triangle-t is a Shape osztályból származtatjuk. 

Ha felidézzük, hogy a destruktorok sokkal jobban hasonlítanak a többi 
tagfüggvényre, mint az egészen kivételes módon kezelt konstruktorok, felme- 
rülhet bennünk a kérdés: lehet-e a destruktor virtuális? Igen, lehet, sőt, sok- 
szor annak is kell lennie. Emlékezzünk vissza, hogy a virtuálisság egy szituá- 
cióban számított: amikor egy ősosztály típusú pointeren vagy referencián ke- 
resztül férünk hozzá egy leszármazott típusú objektumhoz. A virtuális dest- 
ruktorra pedig akkor van szükség, ha az ősosztály típusú pointeren keresztül 
akarunk felszabadítani egy dinamikusan létrehozott, leszármazott típusú ob- 
jektumot, vagyis az ősosztály típusú pointerre hívjuk meg valamelyik delete 
operátort. Ha ezt tesszük, és az ősosztályban van nem virtuális destruktor, a 
viselkedés nem definiált: minden fordító mást csinálhat, és jogában áll például 
rögtön befejezni az alkalmazást."? Vagyis ezt mindenképpen el kell kerül- 
nünk: a destruktort virtuálissá kell tennünk. 





Útmutató: 


— Ha egy destruktort tartalmazó osztályt írva számítanunk kell arra, hogy valaki leszár- 
maztat belőle, deklaráljuk a destruktort vírtuálisnak. 


— Ha egy destruktort tartalmazó osztályban van virtuális függvény, a destruktort is dekla- 
ráljuk vírtuálisnak. 





Mivel a Shape nem tartalmaz destruktort, ez a probléma itt nem merül fel. 

A fenti példa elegáns megoldásában nagy szerepet játszott, hogy a Shape 
osztályon keresztül minden függvényt el tudtunk érni, amelyre szükségünk 
volt. A valóságban ez nem mindig igaz, néha szükségünk van a tömbből kivett 
elem típusára, és aszerint kell feldolgozni. Ekkor megoldás lehet az, hogy a 
különböző kezelést igénylő típusokat külön tömbbe rakjuk. Ha viszont ez 
mégsem lehetséges, akkor szintén a virtuális függvényeket alkalmazhatjuk. 
Elsőként definiálunk egy enum-ot minden egyes típusra. 


.  ehum Shapérypes (ST-RECTANGLE, STCIRCLE, STSOVAREK 


Ha a bővíthetőséget is figyelembe vesszük, akkor lehet, hogy az egyes osztá- 
lyokban definiált konstansok jobb alternatívát kínálnak. Ezt követően meg- 
írunk egy típuslekérdező függvényt: 





5: A gyakorlatban a leszármazott destruktorai hívódnak vagyis legtöbb fordító 
esetén a virtual kulcsszó elhagyásának a tünete memóriaszívássás tes 13 





7.2. Behelyettesíthetőség 
class Shape 


b 
public: 


virtual shapetypes getTypeO-O; 
j 0-0; 








Majd ezt a függvényt felülírjuk minden egyes osztályban. Mintaként álljon itt 
a Circle osztály. 


class Circle: public Shape 
í 


ShapeTypes getTrypeO)( return ST.CIRCLE; ) 
n 


A tömbből kivéve le tudjuk kérdezni az egyes objektumok típusát, így bizton- 
ságosan alkalmazhatunk típuskonverziót a leszármazott irányában. 


forCint iz0;ic3;i44) 
ifCshapes[(i]-2getrype() sz ST. CIRCLE) 
( 


// circle 
Circle" pcircle - (Circler)shapes[li]; 


ja 
else if(shapes(i]-2getrype() — ST. RECTANGLE) 
1 
// Rectangle 
Rectangle "pRectangle - (Rectangle")shapes[i]; 


tú 
else if(shapes[(i]-egetrypeO) --— ST. SOUARE) 
1 

// Sguare 

Sguare "pSguare - (Sguare")shapes[i]; 


: 
delete shapes[i]; 
4 


Figyeljük meg, hogy nem bízunk semmit a véletlenre: nem vezetünk be else 
ágat, mert a hierarchia bővítése esetén (például háromszöggel) helytelen tí- 
puskonverziót alkalmazhatunk. 





Útmutató: A virtuális függvénnyel történő típuslekérdezést csak akkor használjuk, ha nincs 
más megoldás. Ilyen helyzet legtöbbször akkor adódik, amikor más által megírt kódhoz kell al- 
kalmazkodnunk, amelyet nem áll módunkban megváltoztatni. Ha azonban rajtunk múlik a do- 
log, nézzük meg, lehetséges-e egy közös ősosztály bevezetése, amely minden, a leszármazot- 
takra közös funkciót tartalmaz. Ha nem létezik ilyen, ne rakjuk közös tömbbe őket, a közös 
őssel össze nem kapcsolható osztályokat tároljuk külön más-más típusú tömbben. Ha ez nem 
megfelelő, akkor nyugodt lelkiismerettel alkalmazhatjuk a típuslekérdezéses eljárást. 
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Néha látható olyan megoldás, amely akkor is erőlteti a közös ősosztály alkalmazását, ami. 
kor nem lehetséges. Tételezzük fel, hogy szükségünk van valahol a Rectangle::Setb függvényé- 
re. Ezért a Shape osztályban ís írunk egy Setb-t, amelyet a nem Rectangle típusú leszármazott 
osztályokban, ahol ez a művelet nincs értelmezve, valamilyen hibás visszatéréssel implemen- 
tálunk. Ez a megoldás az objektumorientált szemlélet nevében bízvást nevezhető igénytelen. 
nek és mindenképpen kerülendőnek. 





7.3. A virtuális függvények megvalósítása 


A nem virtuális függvények esetében az a cím, amelyre a függvény hívásakor 
ugrani kell, fordítási időben határozódik meg. Egy virtuális függvény pointeren, 
illetve referencián keresztüli hívásakor azonban az a függvénycím, amelyre ug- 
rani kell, csak futási időben dől el, a fordító nem , égetheti be", egyik függvény 
címét sem. Ebben a fejezetben — némi gyakorlással egybekötve — azt vizsgáljuk 
meg, milyen mechanizmust alkalmaz a fordítók többsége a probléma megoldá- 
sára. Természetesen több megoldás is létezik, a CH szabvány nem rögzíti a 
követendő eljárást. A könyv írásakor a legtöbb fordító alapjaiban a következők- 
ben ismertetett megoldást követi. Az alapelvek ismerete nagyban hozzájárulhat 
a virtuális függvények működésének megértéséhez, emellett a hibakeresés s0- 
rán is sok esetben hasznosnak bizonyulhat. 

A megoldás alapja az indirekció. Minden olyan osztály, amelynek van leg- 
alább egy virtuális függvénye (akár benne definiált, akár örökölt), rendelke- 
zik egy táblázattal a virtuális függvények ugrási címeivel. Ezt virtuális ugró- 
táblának szokás nevezni. A táblázat annyi címet tartalmaz, ahány virtuális 
függvénye az adott osztálynak van. 

Az osztály minden objektumának van egy pointere az osztályának virtuális 
ugrótáblájára. A pointerre a vfptr (virtual function table pointer) a leggyakrab- 
ban alkalmazott jelölés. A pointer, bár kódból nem elérhető, minden objektum- 
ban ténylegesen jelen van és helyet foglal. Tekintsük az alábbi kódrészletet: 
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7.3. A virtuális függvények megvalósítása 
A memóriakép ez esetben a következő: 
Az A osztály 


ugrótáblája A at; [/ Az A osztály a1 objektuma 





14. ábra. A virtuális függvénnyel rendelkező A osztály objektumainak memóriaképe 


Osztály kód Osztály ugrótábla ZENET 


class A 
( 
int x; 
public: 
void f1() (...) 
virtual void f2() (...) 
b 
class B: public A 
( 
inty; 
public: 
void f1() (..) 








class C: public B 
( 
int z; 
public: 
void f2() (...) 
virtual void f3() 
k 
class D: public C 
( 
public: 
void f3() (...) 
vírtual void f4() (...) 
k 


15. ábra, Virtuális függvények megvalósítása 
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7. fejezet: Általánosítás és specializáció 


Az A osztály al és a2 objektumában levő víptr is az A osztály ugrótáblájára 
mutat, amelyben esetünkben egyetlen bejegyzés van: az A osztály f1() virtuá- 
lis függvényének címe. A ufptr pointert a legtöbb fejlesztőeszköz nyomkövetés 
(debug) során a többi tagváltozó mellett meg is jeleníti. 

Tekintsük át az ugrótábla alapján történő címfeloldást a 15. ábrán látható, 
összetettebb példa alapján. 

A következőkben gyakorlásképpen néhány használati esetet tekintünk át, 
ennek során kerül sor az ugrótábla alapján történő címfeloldás ismertetésére 
is. A feladat valamennyi esetben annak eldöntése, hogy a hierarchiában mely 
függvényverzió kerül meghívásra. 


1. eset 


eseti 
CO 
c.f2O; 





Mindkét esetben közvetlen (nem pointeren, illetve referencián) keresztüli 
függvényhívás történik, így nincs különbség virtuális és nem virtuális függ- 
vények között. A hierarchiában felfelé haladva a legközelebbi függvény hívó- 
dik meg: c.fI() esetében a B:-fI, c.f20) esetében a C::f2. 





Pointeren keresztüli függvényhívásról van szó, f/ azonban nem virtuális, így 
a pointer típusa dönti el, mely függvény kerül meghívásra. A pa pointer típu- 
sa At, így A:r/1 hívódik meg. 
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Valamennyi esetben pointeren keresztüli függvényhívásról van szó. A hívott 
f2 függvény virtuális, így a mutatott objektum típusa dönti el, mely függvény 
kerül meghívásra. A pointer típusa minden esetben At. A , mutatott" objek- 
tum az első esetben A típusú, így A::/2 hívódik meg. A második esetben a pa 
pointer C típusú objektumra mutat, ez C::(2 meghívását jelenti. A harmadik 
esetben a pa pointer D osztálybeli objektumra mutat, erre vonatkozóan a leg- 
speciálisabb /2 függvény hívódik meg. Mivel az /2 a D osztályban nincs defi- 
niálva, így ez a hierarchiában felfelé haladva a legközelebbi, vagyis a C::f2 
meghívását jelenti. Bár az egyes esetekben más-más függvény hívódik meg, a 
hívó" kód teljesen azonos: 


A fordító által generált kód a virtuális ugrótábla felhasználásával eredményezi 
a megfelelő működést. Az ugrási cím megállapítására vonatkozóan generált kód 
logikailag a következő: cím -— pa-xvfptrf(0]. Vagyis az ugrási cím megállapításá- 
hoz a fordító veszi a pa pointer által mutatott objektumot. Ennek vfptr pointere 
az osztály virtuális ugrótáblájára mutat, a táblázat 0. rekesze pedig az /2 függ- 
vény ugrási címét tartalmazza. A hivatkozások a kiinduló ábra alapján végig- 
vezethetők. A 0. rekesz a teljes hierarchiában az f2 virtuális függvényhez van 
rendelve, minden osztály ugrótáblájában az adott osztály f2 függvényére mutat 
(illetve, ha az adott osztályban nincs felüldefiniálva, akkor legközelebbi olyan 
ősében levőre, ahol az /2 függvény definiált). Gondoljuk végig, hogy ez a megol- 
dás minden pa-:f20; hívás esetén pontosan az elvárt viselkedést eredményezi. 


4. eset 





Ebben az esetben fordítási hibát kapunk. Igaz ugyan, hogy az /3 virtuális és a 
pa által mutatott objektum osztályában (C) létezik is az /3 függvény, de őspoin- 
teren keresztül mindig csak az ősben is definiált függvények érhetők el. Az /3 
függvény az A osztályban pedig még nem került bevezetésre. 


5. eset 
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7. fejezet: Általánosítás és specializáció 


A helyzet nagyon hasonló a 3. esetben vázolthoz, itt is őspointeren keresztüli 
virtuális függvényhívásról van szó, így az alkalmazandó gondolatmenet is azo- 
nos, A hívott függvény most azonban az /2 helyett az f3. A fordító az ugrási cím 
megállapításához logikailag a cím — pc-ovfptr(1] kifejezést használja minden 
esetben. A hierarchiában az osztályok virtuális ugrótáblájában az 1. rekeszben 
az /3 függvény címe szerepel, amely minden esetben úgy van kitöltve, hogy a 
megfelelő /3 függvényverzióra mutasson: C osztálybeli objektumok esetében 
C::f3-ra, D osztálybeli objektumok esetében D::f3-ra. A megoldás a virtuális 
függvények esetében elvárt viselkedést eredményezi. 

A virtuális függvényhívások feloldására bemutatott módszerrel kapcso- 
latban ismételten hangsúlyozzuk, hogy ez csak egy lehetséges megvalósítás, 
az egyes fordítók eltérő megoldásokat alkalmazhatnak. Többszörös öröklésnél 
a helyzet tovább bonyolódik abban az esetben, ha egy osztály több őstől is 
örököl virtuális függvényeket.5? 

Zárógondolatként megjegyezzük, hogy a virtuális függvények megvalósí- 
tásának egyik következménye az alapértelmezett argumentumok virtuális 
függvények esetén történő alkalmazása során tapasztalt, első ránézésre meg- 
lepőnek tűnő viselkedés. Tekintsük meg az alábbi kódrészletet: 





ss. A fordítók által jellemzően alkalmazott megoldásban az objekti i ís; 
1 umok annyi víptr poin! 
tartalmaznak, ahány őstől az objektum osztálya virtuális függvényeket örököl. 
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FSS UTAL Többszörös öröklés 





A Counter egy számlálót megvalósító osztály, a számláló értékét az Increase 
virtuális tagfüggvénnyel lehet növelni. Ennek paraméterében megadható a nö- 
vekmény, melynek alapértelmezett értéke egy. A SpecCounter a Counterből le- 
származott osztály, amely felüldefiniálja az ős Increase tagfüggvényét, mégpe- 
dig úgy, hogy a növekmény paraméter alapértelmezett értéke tíz lesz. A main 
függvényünkben a p pointer SpecCounter osztálybeli objektumra mutat, így a 
p-olnerease() művelethívás során a SpecCounter::Increase() kerül meghívásra. 
A hívás során azonban meglepő módon egy lesz a növekmény, mivel a Counter 
ősosztálybeli alapértelmezett értéket használja fel. Ha jobban belegondolunk, 
ez nem is lehet másként. A fordító az alapértelmezett érték behelyettesítésekor 
csak a pointer típusából indulhat ki (esetünkben Counter"), mert nem tudja 
előre, milyen osztálybeli objektumra mutat futás közben a pointer. A virtuális 
ugrótáblás függvényhívási mechanizmus pedig nem teszi lehetővé az alapér- 
telmezett függvényargumentumok dinamikus, futás közbeni feloldását. 





Útmutató: Virtuális függvények esetén a függvényargumentumoknak ne adjunk meg alapér- 
telmezett értéket. 





7.4. Többszörös öröklés 


Az eddigi példák mindegyikében minden osztálynak egy ősosztálya volt. A Ctt 
nyelvben lehetőség van arra, hogy egy osztálynak több őse legyen. Ekkor 
többszörös öröklésről beszélünk. Az alábbi ábra a szokásos jelölésrendszert 
alkalmazva szemlélteti a többszörös öröklést: 








16. ábra. Többszörös öröklés 


Az ábrán a C osztálynak két őse van: az A és a B osztály. Egy osztálynak ter- 
mészetesen kettőnél több őse is lehet. A többszörös öröklés esetén a leszárma- 
zott osztály valamennyi szülőjének tagváltozóit és tagfüggvényeit örökli. Az 
ábrának megfelelő C-t-t kód a következő: 
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A leszármazott osztály definíciójában az osztály neve után i 

tályt fel kell sorolni vesszővel elválasztva, a Játhatóságot 4 kötés káli mt 
den ősre megadva. Ahol nem adunk meg láthatóságot, ott az alapértelmezett 
private láthatóság érvényes. Gyakorlásképpen nézzük meg, hogy a leszárma- 
zott C osztály objektumai hogyan néznek ki a memóriában: 5 


Cel; 
j20R ÁL 1A 
KEZES E 1s 


17. ábra. Memóriakép többszörös öröklés esetén 


A c! egy C osztálybeli objektum. Az objektumban előszöi 
t e : r az örökölt tagváltozók 
ző balról jobbra alnűvé kerüliék § . öétntat SZA vestól tán 
jet ante § be az obj. : az A lyból a, majd a 
8 követik a leszármazott osztály tagváltozói, esetünkben c. 
eli va eme denet ke is érvényes az a szabály, hogy leszármazott 
Teleky ai et t ősosztály típusú pointerrel vagy ősosztály típusú 
vö tkozni, Természetesen itt is igaz, hogy ekkor úgy tekintünk 
e e minban az adott ősosztálybeli lenne, ennek következtében 
seszeksik pnsztálybeli tagváltozók és tagfüggvények érhetők el (illetve 
: elyeket az ősosztály örökölt a saját szüleitől). A fenti A, B és C osztá- 
iyókatáilhasínábis 1 a vizsgáljuk meg, mit is jelent ez a gyakorlatban: 


hasz ey ab 





7.4. Többszörös öröklés 


Ik, 





A példában definiáltunk egy C leszármazott osztálybeli c! objektumot. Ezt kö- 
vetően definiáltunk három mutatót (minden típusra vonatkozóan egyet), majd 
a mutatókat a c! objektumra állítottuk. Ezután a különböző ősosztályokra mu- 
tató pointerekkel próbáltuk elérni a cl objektum tagváltozóit. A pa-2a — 10; sor 
teljesen rendben van, hiszen egy A" típusú mutatóval próbálunk az A ősosz- 
tályban definiált tagot elérni. A pa-2b — 10; kifejezés viszont fordítási hibát 
okoz. Bár a b tagváltozó része a c! objektumnak, A" ősosztály típusú mutatóval 
nem lehet elérni, hiszen az a B ősosztályban definiált. A következőkben nézzük 
meg a kialakult memóriaképet: 


C"pc,Atpa , Cct; 


B" pb A 


Égi 


18. ábra. Ősosztálybeli pointerek többszörös öröklés esetén 


A legfontosabb tanulság a következő: minden mutató a mutató típusának 
megfelelő rész elejére mutat az objektumban, ami megfelel az elvárá- 
sunknak. Ennek alapján a pc és a pa az objektum elejére mutat. Első pillanat- 
ban furcsának hathat azonban, hogy a B" típusú pb pointer nem az objektum 
elejére mutat, hiszen a B-ből örökölt részek nem itt kezdődnek. Ennek fő kö- 
vetkezménye az, hogy pointerkonverzió esetén a pointer által tartalma- 
zott cím megváltozhat! Erre eddig nem volt példa, ez a többszörös öröklés sa- 
játossága. Természetesen a C-rx fordító olyan kódot generál, amely a konverzió 
során a pointer értékét megfelelő eltolással módosítja. A fordító képességei 
azonban e tekintetben korlátozottak, erre mutat példát az alábbi — a korábbi A, 
B és C osztálydefiníciókra építő — kódrészlet: 





A példában egy C osztálybeli c! objektumból indulunk ki. A C-nek két őse 
van: az A és a B osztály. A második sorban a cl objektumra B" őspointerrel 


n. A harmadik sorban az A" pa - pb: 


hivatkozunk, ezzel minden rendben vai pa; 
ktumra a másik ősosztálybeli pointer- 


kifejezéssel az a célunk, hogy a c! objei 
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rel, At-gal hivatkozzuk. Ez szabályosnak tűnik ugyan (őspointerrel lenne hi. 
vatkozás leszármazottra), ám az egyik ősről (B") a másik ősre (A?) keresztbe 
konverzió közvetlenül nem lehetséges, így fordítási hibát kapunk. A negyedik 
sorban egy explicit konverzióval elkerülhetjük a fordítási hibát, ugyanakkor 
sokkal nagyobb bajt hozunk a fejünkre: futás közben fog az alkalmazásunk 
kiszámíthatatlan módon rosszul működni. Ennek az az oka, hogy a kereszt- 
be konverzió során a fordító nem tudja alkalmazni a szükséges poin- 
tereltolásokat, így sérül az a szabály, hogy a mutató a típusának meg- 
felelő rész elejére mutat az objektumban. Ahhoz ugyanis, a fordító ki- 
számolja, hogy a konverzióhoz szükséges címeltolást, a fordítónak tudnia kel. 
lene, hogy itt a C osztálybeli A, illetve a C osztálybeli B osztályokról van szó. 
Ez az információ azonban nem áll a fordító rendelkezésére, ha önmagukban 
álló A" és B" pointerekkel dolgozunk. Esetünkben mindez azt jelenti, hogy a 
((A")pb)-2a 7 10; kifejezés a c! objektum a tagváltozója helyett a b tagváltozó- 
jának értékét állítja 10-re! A problémára szerencsére van megoldás: a C osz- 
tályt is bevonjuk a konverzióba, így a fordító a konverzió végrehajtásakor a C 
osztály felépítését is figyelembe fogja venni. Vagyis a mutatót előbb konver- 
táljuk a leszármazott típusra (ami a mutatott objektum tényleges típusa), 
majd ezt követően a másik ősre: erre mutat példát a kódrészlet utolsó két so- 
ra. Az utolsó előtti sorban az A?-ra konverzió természetesen el is hagyható, 
elég lenne A" pa -— (C")pb;-t írni. A tanulságokat az alábbi ábra foglalja össze: 


Ne! ete 
(ATM ETBZA 
AY HASZ 
NSZ ok 
3 am zása 


19. ábra. Engedélyezett pointerkonverziók többszörös öröklés esetén 





ÖK 


Amennyiben virtuális függvényekkel dolgozunk, és engedélyezzük a futási ide- 
jű típusinformáció alkalmazását a fordító számára, a dynamic. cast operátor le- 
hetőséget biztosít a keresztbe konverzió alkalmazására. A dynamic cast operá- 
tor alkalmazását a 8.3. A C-t-- típuskonverziós operátorai ismerteti részletesen. 


7.4.1. A többszörös öröklés gyakorlati alkalmazása 


A többszörös öröklést eddig tisztán programozástechnikai szempontból vizs- 
gáltuk, a következőkben gyakorlati alkalmazásának különböző aspektusait 
tekintjük át. Ez azért is különösen fontos, mert a többszörös öröklés nem 
megfelelő alkalmazása számos veszélyt rejt magában. 

Először is lényeges annak tisztázása, hogy a Cs öröklés mint nyelvi esz- 
köz két nagyon is eltérő fogalmat mos össze: az egyik az interfészimple- 
mentáció, a másik az implementáció öröklése. 
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i Interfészimplementáció. Azáltal, hogy egy osztály leszármazik egy má- 
sikból, következik, hogy behelyettesíthető annak helyére. Ez természetes kö- 
vetkezménye annak, hogy az öröklés tulajdonképpen az osztályok közötti álta- 
lánosítás-specializáció logikai kapcsolattípus nyelvi kifejezőeszköze: egy , speci- 
ális" objektumra (pl. Circle, cle, Rectangle) mindig tudunk , általánosként" (pl. Shape) 
gondolni. A behelyettesíthetőségi szabály nyelvi szinten azt jelenti, hogy ősosz- 
tály típusú pointerrel, illetve referenciával lehetséges leszármazott osztálybeli 
objektumra hivatkozni. Amikor egy A osztálybeli objektum egy B osztálybeli ob- 
jektummal kommunikál — például felhasználja céljai megvalósítására —, akkor 
a behelyettesíthetőségi szabály következtében a B osztályból leszármazott tet- 
szőleges objektummal együtt tud működni. Ez természetes, hiszen a B-ben de- 
finiált publikus műveletek a leszármazottban is rendelkezésre állnak, és szük- 
ség szerint felülírhatók (specializálhatók). A B osztály publikus műveleteinek 
halmazára a B osztály objektumainak interfészeként gondolunk. Az öröklést 
mint nyelvi eszközt használhatjuk arra, hogy bizonyos objektumok behelyette- 
síthetők legyenek más objektumok helyébe (például a kör, a téglalap stb. objek- 
tumok alakzatok helyébe). Ennek legnagyobb előnye, hogy a különböző típu- 
sú objektumok egységesen kezelhetők lesznek (közös listában tárolhatók, 
egységesen kirajzolhatók stb.). Másképpen fogalmazva: az öröklést ez esetben 
annak kifejezésére használjuk, hogy a leszármazott objektumok implementál- 
ják, megvalósítják az ős által definiált művelethalmazt, interfészt. Az ősosz- 
tály (például Shape) ebben a vonatkozásban interfészdefiníciónak te- 
kinthető, amely definiálja az interfészben szereplő műveletek halma- 
zát. Ha az objektumokra csak az interfészükön (pl. Shape", Shapeg:) keresztül 
hivatkozunk egy osztályban vagy műveletben, akkor az osztály, illetve művelet 
bármilyen, az adott interfészt implementáló (az adott ősosztályból leszármazó) 
osztály objektumaival használható lesz. Ez szélesebb körben felhasználható, 
könnyebben karbantartható kódot eredményez. 

Implementáció öröklése. Az öröklés alkalmazásának másik következ- 
ménye, hogy a leszármazott osztálybeli objektumok öröklik a szülő tagválto- 
zóit és tagfüggvényeit, így felhasználhatják őket. Az ősosztályból örökölt tag- 
függvények implementációja ezért automatikusan rendelkezésre áll, nem 
kell még egyszer megírni. Az öröklés alkalmazásának előnye ez esetben az, 
hogy kevesebb kódot kell írni, valamint a kód is könnyebben karbantartható 
lesz, mert a leszármazottakra közös kód csak egy helyen, az ősben szerepel. 

Nem szerencsés, de a C-t nyelvben a fenti két fogalom, vagyis az interfész- 
implementációnak és az implementáció öröklésének a különválasztására csak 
korlátozott nyelvi eszközök állnak rendelkezésre. Privát öröklés alkalmazásá- 





54 A Java és a Ctt nyelvekben az öröklés alkalmazása mellett lehetőség van az interfészimp- 
lementáció önálló alkalmazására. Interfészek az interface kulcsszó használatával defini- 
álhatók. Az interfész tisztán műveletek halmaza, nem tartalmazhat tagváltozót, illetve 
műveletimplementációt. Ezen nyelvekben egy osztálynak legfeljebb egy őse lehet (így imple- 
mentációt csak egy helyről örökölhet), de egy osztály több interfészt is implementálhat 
(így több szerepbe behelyettesíthető). 
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7. fejezet: Általánosítás és specializáció 


val tisztán implementációöröklés érhető el: a szülő valamennyi publikus tag: 
függvénye privát lesz, a külvilág számára nem hozzáférhető. Ennek következté- 
ben a leszármazott osztály interfészének nem része a szülő interfésze. A privát 
öröklés alkalmazása azonban viszonylag ritkán használt technika. Tisztán inter. 
fészöröklés alkalmazására nincs nyelvi eszköz (speciális kulcsszavak), de tisztán 
virtuális függvényeket tartalmazó ősosztályok alkalmazásával a gyakorlatban 
szerencsére mégis megvalósítható, erre a későbbiekben példát is mutatunk. 

Többszörös öröklés alkalmazása esetén ugyanakkor hangsúlyozottan fon- 
tos szerepet kap az interfészimplementációnak és az implementáció öröklésé- 
nek a megkülönböztetése. 

Az, hogy egy osztály több interfészt implementáljon, természetes köve- 
telmény és gyakran alkalmazott technika. Ennek jelentése az, hogy egy osz- 
tály több szerepben működhet, többféle szerepben lehet rá hivatkozni. 

Ám, ha egy osztály több őstől örököl implementációt, annak számos kelle- 
metlen következménye lehet. Egyebek között előfordulhat, hogy az osztály több 
ősének is ugyanolyan nevű tagváltozója, illetve tagfüggvénye van, ami névütkö- 
zéshez vezethet.55 Egy másik probléma akkor merül fel, ha egy ős tagváltozója 
több öröklési úton bekerül a leszármazottba (erre példát a 7.5. Virtuális örök- 
lés fejezetben fogunk látni). A bajok egy része megfelelő technikákkal (például 
virtuális öröklés) elkerülhető ugyan, de ezek sok esetben szükségtelenül növe- 
lik a kód bonyolultságát. 





Útmutató: Amennyiben többszörös öröklést alkalmazunk, törekedjünk arra, hogy csak egy 
ősosztálytól örököljünk implementációt. A többi ösosztály legyen tisztán virtuális függvények- 
ből álló, interfész jelentésű osztály. 


A következőben példával mutatjuk be az interfészimplementáció alkalmazását. 





Feladat: 


e Írjunk egy különböző sorrendezési algoritmusokat támogató, a lehető legszélesebb kör- 
ben alkalmazható osztályt (Sorter). Mivel ebből szeretnénk meggazdagodni, a forráskód- 
ját nem kívánjuk kiadni, csak a lefordított kódot statikus programkönyvtár (.Lib, .a) vagy 
tárgykódú állomány (.obj, .o) formájában. 


s Írjunk egy olyan osztályt (Serializer), amely a lehető legszélesebb körben támogatja ob: 
jektumok adatfolyamba írását, illetve onnan való beolvasását. Ezt a két szolgáltatást 
együttesen sorosításnak nevezzük. Ez esetben is fontos szempont a forráskód védelme. 


e Írjunk személy objektumokat reprezentálni képes osztályt. Az osztály neve legyen 
Person. Az osztályt Úgy. írjuk meg, hogy a Person objektumok tömbje sorrendezhető le- 
gyen a Sorter osztállyal (az összehasonlítás alapja az életkor legyen), az objektumok 
pedig a Serializer osztállyal adatfolyamba írhatók és onnan beolvashatók tegyenek. 





55 zlyemégtere azonos nevű (és paraméterlistájú) tisztán virtuális függvényt örököl 
t ) ősétől, az nem okoz ütközést. Ez esetben ugyanis az ősben nincs függvényimplemen- 
táció, így a fordítónak nem is kell választania az implementációk között. 
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A munkát a Sorter sorrendező osztály megvalósításával kezdjük. Minden sor- 
rendező algoritmushoz egy megfelelő statikus tagfüggvényt vezetünk be: 
BubbleSort, GduickSort stb. El kell döntenünk, hogy a sorrendező tagfüggvé- 
nyek milyen formában kapják meg a sorrendezendő objektumokat. A Sorter 
osztályt tudni kell alkalmazni a Person objektumok esetében, ezért gondol- 
hatnánk a Person""-ra (Person objektumokra mutató pointerek tömbjére). Ez 
azonban két okból sem használható: egyrészt kikötöttük, hogy a Sorter nem- 
csak a Person osztály esetében, hanem a lehető legszélesebb körben legyen 
felhasználható, már lefordított formában is. Felmerülhet a void"? (void? mu- 
tatókkal hivatkozott objektumok tömbjének címe), de ezt a megoldást is gyor- 
san el kell vetnünk: void" által mutatott objektumokra semmi sem hívható, a 
sorrendező algoritmusnak pedig egy megfelelő összehasonlító függvény hívá- 
sával össze kell tudnia hasonlítani az objektumokat a rendezéshez. A megol- 
dást az IComparable interfész (csak tisztán virtuális függvényeket tartalmazó 
absztrakt ősosztály) bevezetése jelenti: 


// File: ICcomparable.h 
ttifndef ICOMPARABLE H 
$define ICOMPARABLE H 


class IComparable 


tí 
public: 

virtual bool operatoráz(const IComparableg)-0; 
h 


áendif /" ICOMPARABLE H §/ 


Az interfész nem más, mint tisztán virtuális függvényekből álló absztrakt osz- 
tály: az interfészben szereplő műveletek, operátorok felsorolása. Esetünkben az 
interfész egyetlen operátorból áll, ennek megléte már lehetővé teszi a sorrende- 
zést. Amennyiben egy osztályt interfész szerepben használunk fel, bevett gya- 
korlat az , prefix alkalmazása, de ezt természetesen nem kötelező követni. 
Sorter osztályunk megvalósítása az IComparable felhasználásával a következő: 


/7 File: Sorter.h 
Hifndef SORTER H 
$define SORTER H 
$include "Icomparable.h" 


class Sorter 


13 
public: É 
static void Bubblesort(rcomparablet" prtems, unsigned itemcount); 
static void Ouicksort(Icomparable tt prtems, unsigned itemCount); 
. // További algoritmusok metódusai ú bt A 


s lork Ne zet at all 
; B 


143 

















A megoldás általános, hiszen tetszőleges, az IComparable interfészt implemen- 
táló (vagyis IComparable osztályból leszármazott) osztály esetében használható. 
Az IComparablte interfészben definiált operatorc a "1-gyel megjelölt sorban sze- 
repel. Az objektumokra más függvény, operátor nem hívódik. Ebből a szem- 
pontból megtévesztő lehet a "2-vel megjelölt sorban az operator- használata, de 
ha jól megnézzük, ez nem az IComparable objektumokra, hanem ezek címeire, 
vagyis IComparable" pointerekre hívódik. Ennek megfelelően a pointerek értéke 
másolódik a szabványos pointeraritmetikának megfelelően. 

Célunk volt, hogy a Sorter algoritmusait a Person osztály objektumai ese- 
tén is alkalmazni lehessen. Ennek mindössze egy feltétele van: a Person 05Z- 
tálynak implementálnia kell az IComparable interfészt: 
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— — SS E E ee TÉT 


— int main 


.  peoplef0] - 
people[1] 
peoplef[2] 
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a 





Bizonyára felmerül a Kedves Olvasóban, hogy miért van szükség a Persont 
pointerek IComparable" pointereket tartalmazó tömbbe másolására (compa- 
rables), vagyis miért nem jó az alábbi megoldás: 


Ha kipróbáljuk, ez a megoldás bizony nem fordul le. A BubbleSort függvény 
IComparable"" pointert vár, itt pedig Person"" típusú pointert adunk át. A ta- 
nulság: Person?-ról IComparable"-ra van automatikus konverzió, Person"?-ról 
IComparable""-ra viszont nincs. Explicit konverzióval kikényszeríthető a meg- 
oldás elfogadása: 





Ez lefordul és esetünkben , véletlenül" még jól is működne, de általánosságá- 
ban ez a megoldás nem alkalmazható (így mi sem használjuk). Többszörös 
öröklés esetén (például, ha a Person osztály több interfészt implementál) a 
fordító nem tudja alkalmazni a szükséges pointereltolásokat, ami futási idejű 
hibához vezet. Ez a példa kapcsán a későbbiekben — a sorosítástámogatás be- 
vezetését követően — minket is közvetlenül érinteni fog. 

A következő lépésben az egy adatfolyamba írást és az adatfolyamból olva- 
sást támogató Serializer osztályt írjuk meg. A gondolatmenet megegyezik a 
Sorter osztály esetében alkalmazottal: az objektumokra csak egy általános in- 
terfészen keresztül történik hivatkozás. Nevezzük ezt ISerializable-nek. Az 
interfész ez esetben két műveletből áll: 
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Az interfészt implementáló osztályok példányainak a Save műveletben ki kell 
írniuk az objektum állapotát a paraméterben megkapott ostream-be, a Load 
műveletben pedig be kell tölteniük a paraméterben megkapott istream-ből. 
A Serializer osztály bármilyen objektummal használható, amely implemen- 
tálja az ISerializable interfészt: 


// File: Serializer.h ú 
fifndef SERIALIZER H É f . e; 
$define SERIALIZER H 

include ciostreams 

finclude "ISerializable.h" 

using namespace std; 


class Serializer 
1 
public: 
// os: kimeneti adatfolyam. 
// pitems: mutató az adafolyamba kiírandó ISerializable-t 
// implementáló objektumok tömbjére. 
// itemcount: elemek száma a pItems tömbben. 
static void Saveobjects(ostreamé os, ISerializablett pitems, 
unsigned itemCount); 


// is: bemeneti adatfolyam, 
// piItems: mutató az adafolyamból beolvasandó ISerializable-t 
// implementáló objektumok tömbjére. 
// itemcount: a beolvasandó elemek száma (elemszám a piItems 
// tömbben) 
// Lényeges: feltesszük, hogy pItems elemei már érvényes 
// objektumokra mutatnak! 
static void Loadobjects(istreamg is, ISerializablett pItems, 
unsigned itemcCount); 
3; 


$endif /" SERIALIZER H §/ 


// File: Serialízer.cpp 
$finclude "Serializer.h" 


void serializer: :Saveobjects(ostreamg os, ISerializabler" pitems, 
unsigned itemcount) 


1 
ífC(!os) 
35 
cerr cz "output stream is not open!" cc endi; 
return ; így 
) 8 


for(unsigned int í-0; isitemcount; tri) 
pitems[(i1]-2Save(os) ; 


147 








7. fejezet: Általánosítás és specializáció 


E TEJEZET MGO LÉ b e aa 


A következőkben a Person osztályt bővítjük: most már nemcsak az ICompa- 
rable, hanem az ISerializable interfészt is támogatnia kell, mivel a Serializer 
osztállyal is kívánjuk használni. Ettől a ponttól kezdve a Person osztály több- 
szörös öröklést alkalmaz: 
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77 Mentés 
cout cc "Saving Person objects (not sorted)." cc endl; 
ofstream os(path); 
Iserialízablet serjalizables [maxPeople] ; 
for Cint i 50; ic maxpPeople; tri) 

serjalizables[1] - people[i]; 
serjalizer : : saveobjects (os , serjalizables, maxPeople); 
os.closeO; 
cout cz "Press any key to continue. . ." az endi; 
getcharO; 


// rtt akár át is írhatjuk a fájl tartalmát 


// Betöltés 

cout ex "Loading Person objects." cc endi; 

ifstream is(path); 

serializer: :Loadobjects(is, seriali zables, maxPeop1e); 
is.closeO; 


// Sorrendezés 

xcomparables comparables[maxPeoplel]; 

int i; 

for Gi - 0; i c maxPeople; i4r) 
comparables[fi] - peopleli]; 


Sorter: :Bubblesort(comparables , maxPeople); 


// Mentés sorrendezve 

cout cc "Saving Person objects (sorted)." cc endi; 

ofstream os2(path); 

Iserializablet serjalizables2 [maxPeople]; 

for Cint i -— 0; i c maxPeople; ri) 
serializablesz[i] - (Person")comparables[i]; 


Serializer::Saveobjects(os2, serializables2, maxPeople); 
052.close(); 


// Felszabadítás 
cout cc "Freeing Person objects in memory." cc endi; 
for(unsigned int i - 0; i c maxPeople; i14-4) 

delete people[i]; 


getcharO ; 
: 


Foglaljuk össze a példa kapcsán az interfészek alkalmazásával kapcsolatban 
szerzett tapasztalatainkat. 


e Az IComparable és az ISerializable interfész bevezetése lehetővé te- 


szi, hogy a Sorter és a Serializer osztály bármilyen, ezen interfészeket 
implementáló osztállyal használható legyen. 
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e A megoldás lehetővé teszi, hogy a Sorter és a Serializer osztály kódja 
előre lefordítható legyen és a felhasználáshoz csak bináris formában 
kelljen publikálni. 


e A Sorter és a Serializer osztály kódja szabadon módosítható, míg a vál- 
toztatások az IComparable és az ISerializable interfészt nem érintik. 
Az ezeket használó kódot a változtatások egyáltalán nem érintik: a kód 
újrafordítására sincs szükség, mindössze a linkelést kell megoldani. 


e A orter és a Serializer osztály nemcsak egy adott osztály objektumai- 
val, hanem azok teljes hierarchiájával használható. Példánkban ez 
azt jelenti, hogy bevezethetünk új, a Person osztályból leszármazott 
osztályokat (pl. Employee, Boss stb.), ezeket vegyesen tárolhatjuk egy 
Person? elemtípusú tárolóban, és vegyes objektumokat tartalmazó po- 
intertömbbel is használhatjuk a Sorter és a Serializer osztályokat. Új, 
a Person osztályból leszármazott osztályok bevezetésekor nem kell 
módosítani a meglevő kódot (a Sorter, Serializer, Person osztályok 
kódját)! Rendszerünk könnyen kiterjeszthető: kevesebb programozói 
hibát fogunk elkövetni, nincs szükség a meglevő kód újratesztelésére, 
vagyis időt és energiát takarítunk meg. 


e Annak, hogy az interfészeket absztrakt osztállyal valósítjuk meg, van 
egy kellemes következménye: az interfészeket megvalósító osztályok 
nem példányosíthatók. Ez így van rendjén, hiszen ha belegondolunk, 
IComparable és ISerializable osztálybeli objektumok létrehozásának 
nem is volna értelme. 


Az utolsó előtti pont kapcsán azonnal meg is jegyezzük, hogy a példánkban az 
állítás a sorosításra vonatkozóan a speciális körülmények miatt nem áll fent: 
a Serializer kódja ugyanis felteszi, hogy a betöltendő objektumok a tömbben 
már léteznek: mégpedig, ha különböző típusúak az objektumok, akkor az 
adatfolyamban szereplő sorrendben (ahogy a fájlban volt). A teljes értékű ál- 
talános megoldás lényegesen bonyolultabb lett volna, célunk azonban az in- 
terfészek alkalmazásának szemléltetése volt egy viszonylag egyszerű példán 
keresztül. Az 14. fejezetben ismertetett esettanulmány megmutatja, hogyan 
lehet általánosan megoldani a beolvasást. A példában szintén kötöttséget je- 
lent, hogy a Sorter és a Serializer osztály egy elég nehézkesen használható 
pointertömbben kapja meg az adatokat. Az általános megoldás azonban ké- 
sőbbiekben ismertetett fogalmakra és eszközökre építene (iterátor, sablon). 
A hibakezelés szintén hagy kívánnivalót maga után: a gyakorlatban a példá- 
ban bemutatottnál szélesebb körű hibakezelésre van szükség. Ez elegánsan 
csak kivételkezeléssel oldható meg, amelyről szintén a későbbiekben lesz szó. 
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KS elvsettlíetánávmakza birtak köseszséntbe ee EEKNttTmTteüüüülü..//.o 


7.4.2. A többszörös öröklés és a void" 


Bár a void" ,típustalan" pointerek használatát általánosságban is célszerű 
kerülni, különösen igaz ez többszörös öröklés alkalmazása esetén. A probléma 
ez esetben az, hogy ha egy pointert voidt-ra konvertálunk, akkor elveszik a 
típusinformáció. Ennek következtében a fordító nem tudja alkalmazni a 
szükséges pointereltolásokat! Ezt az alábbi kódrészlet alapján világítjuk meg: 





Az f1 függvényben a c! egy C osztálybeli objektum. Az f! második sorában er- 
re egy B" típusú pb őspointerrel hivatkozunk. Mint tudjuk, pb nem az objek- 
tum elejére mutat. Ezt követően meghívjuk az f2 függvényt, melynek paramé- 
terként átadjuk a pb pointert. Ennek során automatikus Bt) void" konverzió 
történik, ami nem állítja vissza a pointert az objektum elejére. Az f2 függvény 
első sorában annak tudatában, hogy a pv egy C típusú objektumra mutat, a 
pu pointert Cr-ra konvertáljuk, ami void" C" konverziót jelent. Ennek során 
sem történik pointer eltolás, hiszen ennek a jelentése mindössze a következő: 
értelmezd úgy a pu pointert, mint C" mutatót. Ekkor már sejthető, hogy ebből 
bizony baj lesz: a pc egy C" típusú mutató, amely nem az objektum elejére 
mutat. A pc-2c-10; kifejezés így nem a c tagváltozóhoz tartozó memóriare- 
keszbe ír, ami hibás működéshez vezet. Először talán meglepőnek tűnhet, de 
a pc-zcfuncO; művelethívás is kellemetlen meglepetést tartogat: a tagfügg 
vény által megkapott this mutató értéke hibás, hiszen nem az objektum elejére 
mutat. Ennél is nagyobb a baj (már ha lehet ilyet kijelenteni), ha a cfunc függ- 
vény virtuális. Ez esetben a virtuális ugrótábla címzése romlik el teljesen. 
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Az f2 függvény első sorában a C" pc -— (C")pu; kifejezésnél a fordítónak po- 
intereltolásos Bt2Ct konverziót kellene alkalmaznia a pv-re vonatkozóan. 
A fordító azonban nem tudja, hogy a pv egy C típusú objektum B részére mu- 
tat, mivel void?" mutatóval bármire lehet mutatni. A megoldásunkat működő- 
képessé tehetjük, ha a konverzióba nemcsak a C-t, hanem a B-t is bevonjuk, 
vagyis az /2 függvény első sorát a következőre cseréljük: C" pc — (C((BY9pu;. 
Vagyis szem előtt tartva, hogy a c! objektum címét Bt-ként adtuk át, a pu po- 
intert előbb Bt-ra konvertáljuk (void"2B"), majd ezt konvertáljuk Ct-ra 
(Bt3 C"), aminek során már megtörténik a szükséges pointereltolás. 

Sajnos a void" paraméter esetén egyáltalán nem biztos, hogy a void? mu- 
tató valójában C típusú objektum B részére mutat, ezért ezt a konverziót koc- 
kázatos elvégezni. Az igazi megoldás az, hogy az /2 függvényben B" típusú po- 
intert veszünk át, a void" függvényparamétereket pedig kerüljük. Ez logikus 
is, mivel gyakorlatilag a void?-ra történő konverzióval kikapcsoljuk a pointer 
típusellenőrzését. 

Figyeljük meg, milyen nehéz volt észrevenni a problémát a void?" paramé- 
terű megoldásnál: az f2 tagfüggvényben tudtuk, hogy C osztálybeli objektum- 
ra mutatunk, a típusának megfelelő C"-ra konvertáltuk a mutatót, és még- 
sem működött jól! A problémára a dynamic. cast operátor (lásd 8.3. A Ct-t tí- 
puskonverziós operátorai fejezet) sem jelent megoldást, ugyanis void" típusú 
pointerekre nem alkalmazható. 





MNÉLERNRÉSÉNÉRS ELSE SA SSERÉTEt SSE LESZEL SSSS ESZE e ET EKEEEOSETTSI 
Útmutató: Hacsak lehet, kerüljük el a void" mutatók használatát! Különösen igaz ez több- E) 


szörös öröklés esetén. 





7.5. Virtuális öröklés 


"Többszörös öröklés esetén előfordulhat, hogy egy ősosztály tagváltozói az 
öröklési hierarchiában több útvonalon is bekerülnek a leszármazott osztály- 
ba. Erre láthatunk példát az alábbiakban. 


D 
20. ábra. Gyémántforma az öröklési hierarchiában 





A B és a C osztály A-ból származik le, így örökli az A tagváltozóit. A D osz- 
tálynak őse B és C is, ennek következtében az A tagváltozóit mindkét ágon 
örökli. Ezt az elrendezést gyémántformának is szokás nevezni, és a fentinél 
komplexebb öröklési hierarchia esetén is fennállhat. Erre láthatunk példát a 
következő ábrán. 
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21. ábra. Összetett gyémántforma az öröklési hierarchiában 


A G osztályba az A osztály tagváltozói két útvonalon is bekerülnek. A követ- 
kezőkben nézzük meg az egyszerű gyémántformában szereplő osztályok defi- 
nícióját: 





Ddt; 
BZZAST E 6 
ears § et? 
[docAuthor] 


22. ábra. A D osztálybeli objektumok memóriaképe 











záltsze kétszer is 
szerepel. A printf("od", a); kifejezésben altdraltó nem fúdja. eldönteni, melyik 
a változóra gondoltunk, így kétértelműségi hibát jelez. A megoldás egyszerű, 
csupán egyértelművé kell tenni szándékunkat a hatókör operátorral: ameny- 
nyiben a B ágon örökölt a tagváltozó értékét kívánjuk elérni, a B:ra kifejezést 
kell használnunk, ha pedig a a C ágon örököltet, akkor értelemszerűen a Csa 
kifejezést alkalmazzuk. A helyes kódrészlet a lényeget kiemelve ennek megfe- 
lelően a következő: 


Bár általában nem jó ötlet publikussá tenni a tagváltozókat, most tegyük fel, 
hogy az előző példában az A osztály a tagváltozója publikus. Ez esetben a 
main függvényben értelmet nyer a következő: 


A dl.a - I; sor itt is kétértelműségi problémát okoz, de a hatókör operátor meg- 
felelő alkalmazásával jelen esetben is egyértelművé tehetjük szándékunkat: 





A következőkben az előző példa osztálydefinícióit felhasználva gyakoroljuk a 
pointerek használatát: 
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A példában a szokásos módon különböző típusú őspointerekkel hivatkozunk a le- 
származott D osztálybeli d1 objektumra. A kialakult memóriakép a következő: 


D"pd, Btpb, Atpat  Ddt; 
ESZT 
B 
C" pc, A" pa2 ETETETT] 
[ESSSDEMÍHA LD 
HENZÍS ESÉTŐ 
23. ábra. Memóriakép a példában 


Amikor a példában az pa - $d1; kifejezésben A" pointerrel hivatkoznánk a d1 
objektumra, kétértelműségi hibát kapunk. Az A" pointernek az objektumban az 
A-ból örökölt rész elejére kell mutatnia. Mivel két ilyen rész is van, a fordító 
nem tud dönteni. Ezt azonban könnyen egyértelművé tehetjük számára, erre 
mutat példát a fenti kódrészlet utolsó két sora: pa — (B")$-d1; és pa - (C")$d1;. 

Mindeddig elfogadtuk, hogy a gyémántformát tartalmazó öröklés eseté- 
ben a több ágon örökölt ősosztály tagváltozói többször szerepelnek az osztá- 
lyunkban. Amennyiben ezek az objektumunk állapotának különböző független 
részleteit reprezentálják, ez megfelel a várt működésnek. Ámde sokszor azt 
szeretnénk elérni, hogy csak egyszer szerepeljenek, mert a valóság ugyanazon 
elemét reprezentálják. Erre mutatunk egy példát a következőkben. Tegyük 
fel, hogy adatfolyamok kezeléséhez készítünk stream osztályokat. Egy lehet- 
séges megoldás a következő: 


( Steam ] 


ESZ 





f 1Stream )  ( OStream 














24. ábra. Stream osztályok egy lehetséges hierarchiája 
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Az egyes osztályok szerepe példánkban a következő: 


.  Stream: az adatfolyam állapotára vonatkozó információt tárol. Ilyen 
például a folyam megnyitott vagy lezárt állapota, nevezzük az ezt tá- 
roló tagváltozót streamState-nek. 


. Köll input stream, adatok beolvasását támogató osztályok ősosz- 
ya. 


s — OStream: output stream, adatok kiírását támogató osztályok ősosztálya. 


e — IOStream: input-output stream, adatok beolvasását és kiírását egy- 
aránt támogató osztályok ősosztálya. Tegyük fel, hogy többszörös 
örökléssel kerül megvalósításra. 


e  StrStream: stringből olvasást és stringbe írást támogató input/output 
stream. 


e — FileStream: fájlból olvasást és fájlba írást támogató input/output 
stream. 


A példában a gyémántforma jól megfigyelhető: az JOStream és annak leszár- 
mazottai a Stream tagváltozóit (pl. streamState) két ágon is öröklik, így két 
példányban vannak jelen. Ez azonban egyáltalán nem logikus: az JOStream 
objektumokban csak egy streamState tagváltozónak van értelme. Az adott 
adatfolyam vagy meg van nyitva, vagy le van zárva attól függetlenül, hogy ol- 
vasni vagy írni szeretnénk. 

Amennyiben azt szeretnénk elérni, hogy a több ágon örökölt tagváltozók 
csak egyszer szerepeljenek a leszármazott osztályban, virtuális öröklést 
kell alkalmaznunk. Már most leszögezzük, hogy a virtuális öröklésnek semmi 
köze sincs a virtuális függvényekhez! Jelentősségük sem mérhető össze. Míg a 
virtuális függvények objektumorientált eszköztárunk talán legfontosabb kel- 
lékei, addig a virtuális öröklést csak a legritkább esetben vesszük elő. A meg- 
oldást stream példánk esetében az jelenti, hogy az IStream és OStream osztá- 
lyokat virtuálisan leszármaztatjuk le a Stream osztályból: 





A Stream osztály az IStream és az OStream osztály virtuális alaposztálya. 
A virtuális alaposztály tagváltozói csak egyszer szerepelnek a leszármazott- 
ban, de ehhez — mint a példában is látható — minden öröklési ágon virtuális 
alaposztályként kell definiálni őket. A virtuális öröklés alkalmazásának né- 
hány következménye: 
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e — A fejezet elején felvetett többértelműségi problémák nem jelentkeznek, 


e A virtuális alaj 


posztályok tagváltozóinak elérése szükségszerűen köz. 


vetett módon történik. Ennek miértjét a későbbiekben magyarázzuk 
meg. A következménye, hogy a virtuális öröklés alkalmazása jelentős 
teljesítményromlással járhat. 


e — Befolyásolja a konstruktorok hívási sorrendjét (lásd 7.6. A konstruktorok 
és destruktorok automatikus feladatai fejezet). 


A virtuális öröklés alkalmazása némileg bonyolultabbá teszi az objektumok 
felépítését, aminek szükségszerűségére az alábbiakban világítunk rá. Ez ha- 
ladó témakörnek tekinthető, s bár ismerete nem szükséges ahhoz, hogy he- 
lyesen tudjuk alkalmazni a virtuális öröklést, mindenképpen segíti a megér- 
tését. Térjünk vissza a fejezet elején bevezetett A, B, C és D osztályokhoz, de 
most virtuális öröklést alkalmazva: 





Az objektumok memóriabeli reprezentációja fordítófüggő, tekintsünk egy le- 


hetséges megoldást: 
A at 
JA 
B bt; 
EHESZET ÍS 
JEEZ [S 


D"pd,Btpb  Ddt: 


C" pc 


A" pa 


o 
o 








7.6. A konstruktorok és destruktorok automatikus feladatai 


Virtuális öröklés esetén felborul az a szabály, hogy egy objektum tisztán az 
egyes őseiből örökölt, valamint a saját részek szekvenciájából áll. A D osztály 
objektumai B és C részből állnak, de az ezekben levő A-ból örökölt tagok csak 
egyszer, megosztottan szerepelnek. Így nem tehetők egyértelműen sem a B-ből, 
sem a C-ből örökölt részbe. A fenti megoldásban a megosztott részek (a virtuá- 
lis alaposztály tagváltozói, esetünkben a) minden osztály esetében az objektum 
végére kerülnek. Ennek következtében ezeknek a tagváltozóknak az eléréséhez 
nem lehet egy, az objektum elejére vonatkozó fix eltolást alkalmazni, mert az 
egyes leszármazott osztályok esetében ez más és más. A megoldást az indirek- 
ció alkalmazása jelenti. Az egyes osztályok virtuális alaposztályonként rendel- 
keznek egy virtuális bázispointer-táblázatra mutató pointerrel (vbptr). A táblá- 
zatban az egyes osztályok esetében a virtuális tagok eléréséhez szükséges elto- 
lás értékei szerepelnek. A virtuális alaposztály tagváltozóinak elérése közvetett 
módon, a ubptr pointer által mutatott eltolás alkalmazásával történik. Ebből 
ered a korábban említett teljesítménycsökkenés. Ismételten hangsúlyozzuk, 
hogy az objektumok reprezentációja és a virtuális öröklés megvalósításának 
mechanizmusa fordítófüggő, építeni nem szabad rá. Ismertetésével mindössze 
az volt a célunk, hogy rávilágítsunk viszonylag bonyolult mivoltára, és kellő- 
képpen elrettentsünk mindenkit a C nyelvből esetleg átmentett bitbabráló 
(úgyis pontosan tudom, hogy néz ki a memóriában") hozzáállástól. 


7.6. A konstruktorok és destruktorok automatikus 
feladatai 


Az eddigiek során már találkoztunk olyan függvényekkel, amelyek automati- 
kusan, explicit hívás nélkül futnak le. Ilyenek a konstruktorok és a destruk- 
torok. Sőt, a fejezet elején, az öröklés tárgyalásánál az is kiderült, hogy ha az 
ősosztály argumentum nélküli, alapértelmezett konstruktorát szeretnénk 
meghívni, azt nem kell külön jelezni, automatikusan meghívódik. Ha ez nem 
megfelelő számunkra, akkor a konstruktor fejlécétől kettősponttal elválasztva 
kell meghívni a megfelelő, nem üres paraméterlistájú konstruktort. Ebben a 
fejezetben megvizsgáljuk az automatikus konstruktor- és destruktorhíváso- 
kat, azok sorrendjét és következményeit. 
Elsőként tanulmányozzuk az alábbi kódrészletet! 
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7.6. A konstruktorok és destruktorok automatikus feladatai 
Az osztályhierarchát az alábbi ábra mutatja. 








26. ábra. A példa osztályhierarchiája 


A hierarchia egy virtuális alaposztállyal indul (BaseClass). Ebből származik 
egy középső osztály (MiddleClass), amelyet egy abból származó másik osztály 
követ az öröklési hierarchiában (MiddleClass2). A hierarchia legalján a Class 
nevű osztály áll, amely a MiddleClass2-ből származik. A program jól illuszt- 
rálja a konstruktorok és a destruktorok hívási sorrendjét. A program kimenete 
az alábbi: 





160 161 

















7. fejezet: Általánosítás és specializáció 
Vagyis a Class c objektum inicializálása során az alábbi konstruktorok hívág. 


tak meg: 


1. virtuális alaposztály(ok) konstruktora 


2. anem virtuális közvetlen ősosztály(ok) konstruktora 


3. a saját rész felépítése 
a) a virtuális alaposztály(ok) elérhetővé tétele 
b) a virtuális függvénytáblák pointereinek beállítása 
c) atagváltozók konstruktorainak meghívása 


4. a programozó által definiált rész (a konstruktor törzsének) futtatása 


Érdemes észrevennünk, hogy a 2. lépés egyfajta rekurziót jelent. A Class köz: 
vetlen ősosztálya a MiddleClass2, és a második lépésben épül fel a Class tí. 
pusú c objektum MiddleClass2 része. Ehhez a MiddleClass2-re nem fut le az 
első lépés, mert a virtuális alaposztályok már felépültek, ugyanakkor a fo- 
lyamat a 2. lépésként elkezdi felépíteni a MiddleClass részt mint közvetlen 
ősosztályt. A MiddleClass alaposztálya már felépült, nincs neki más ősosztá- 
lya, lefut a programozó által megadott rész: kiíródik a MiddleClass konstruk- 
torában megadott szöveg. Ezek után a MiddleClass2 felépülése folytatódik, 
amelyet a 2. lépésnél hagytunk magára. Végrehajtódik a 3. lépés, majd a 4. 
lépés során kiírja a konstruktorban megadott szöveget. A 2. lépésnél magára 
hagyott Class is folytatódik a 3. lépésnél, majd kiírja a megadott szöveget. 





-] Gyakorlat: Keressük meg a CD-mellékleten a fejezethez tartozó könyvtárban az automati- 
kus.cpp állományt, és helyezzünk el egy töréspontot minden konstruktorban! Kövessük végig a 
fent megadott listát figyelemmel kísérve, hogy milyen sorrendben hívódnak meg a konstruktorok! 





A példán jól lehet látni, hogy-a destruktorok hívási sorrendje a konstruktorok 
hívásának éppen az ellenkezője: 


1. a destruktornak a programozó által megadott része (a destruktor törzse) 
2. atagváltozók destruktorai 


3. a közvetlen, nem virtuális ősosztály(ok) destruktora 


4. virtuális alaposztály(ok) destruktora 


Itt a harmadik lépés jelent egyfajta rekurziót. 
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7.6. A konstruktorok és destruktorok automatikus feladatai 





Gyakorlat: Keressük meg a CD mellékleten a fejezethez tartozó könyvtárban az automati- 
kus.cpp állományt, tág helyezzünk el egy töréspontot minden destruktorban! Kövessük végig a 
fent megadott listát figyelemmel kísérve, hogy milyen sorrendben hívódnak meg a destruktorok! 





A fenti sorrend ismerete általában nem a C--t legfontosabb része, viszont né- 
hány következménye váratlanul érhet minket. A konstruktorok hívási sor- 
rendjéből jól látható, hogy az ősosztály konstruktorainak hívása (2. lépés) 
megelőzi a virtuális függvénymutatók átállítását (3. b lépés). Vagyis, ha egy 
ősosztály konstruktorából hívunk egy virtuális függvényt, akkor az ősosztály 
megfelelő függvénye fog meghívódni, és nem a leszármazotté, ahogy várnánk. 
Ha ráadásul ez a függvény tisztán virtuális, linkerhibát kapunk. Tekintsük 
meg az alábbi példát! 


ttinclude ciostreams 
using namespace std; 


class Shape 


hé 

public: 
Shape()( cout cc AreaO); ; // Ezt úgysem példányosítjuk. .. 
virtual double AreaC()-0; 

3 


cláss Rectangle: public Shape 


double a,b; 

public: 
Rectangle(double a, double b):aCa),bCb)( 
double Area()( return atb; 3 

hö 


int mainO 
1 
Rectangle rect(10,20); 


return 0; 


§ 


A fordító tudja, hogy a Shape konstruktorának hívásakor még nem állítódnak 
be a virtuális függvények pointerei, ezért a Shape::Area függvény hívását for- 
dítja be a kódba. Mivel a Shape::Area függvénynek nincs törzse, csak deklará- 
ciója, a linker nem találja a megfelelő függvényhívást, és hibaüzenetet ad. 

A destruktorok esetén a tisztán virtuális destruktor jelent problémát. A 3. 
lépés rekurzív volta miatt az ősosztály destruktora mindenképp meghívódik. 
Ha az tisztán virtuális, vagyis csak a deklarációja létezik, de a definíciója, a 
törzse nem, ez ismét linkerhibát eredményez. Ezért a tisztán virtuális destruk- 
tornak — bármilyen furcsa is — törzset kell definiálnunk, amely jellemzően üres: 
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meglepő, hogy az üres törzsű destruktorral ellentétben 
SEEsátBi destruktorral találkozik a Ct- szoftverfej. 


lesztő, és bízvást állíthatjuk, hogy ez így van jól. 


Ezek után talán nem 
viszonylag kevés tisztán 





NYOLCADIK FEJEZET 


Típuskonverziók 


Már eddig is többször észrevehettük, hogy bár a C-t típuskonverziói nagyban 
hasonlítanak a C nyelvre, mégis tapasztalhatunk különbségeket. Ennek egy- 
felől az az oka, hogy a C--t fejlesztői kezdettől fogva törekedtek rá, hogy a C- 
nél biztonságosabb nyelvet alkossanak. Ebből a C újabb szabványai sok min- 
dent átvettek. Másfelől a Ct-t-ban megjelennek teljesen új, objektumorientált 
nyelvi elemek, amelyekhez új típuskonverziók tartoznak: az előző fejezetben 
láttuk, hogy publikusan örökölt ősosztályra létezik automatikus típuskonver- 
zió. A referenciatípusra szintén vonatkoznak konverziós szabályok, amelyek 
értelemszerűen csak a Ct-4 nyelvben jelennek meg. A típustámogatás C-t 
alapelvét követve lehetőségünk van arra, hogy beépített automatikus típus- 
konverziókat írjunk saját osztályaink számára. Végül pedig a C-H-- finomítja 
az egyetlen C konverziós operátort: annak funkciója szerint négy konverziós 
operátort különböztet meg. 

Ebben a fejezetben bemutatjuk a Ct- típuskonverziók szabályait, az osz- 
tályok konverziós konstruktorait és operátorait, valamint az új konverziós 
operátorokat. 


8.1. Beépített típusok közti típuskonverziók 


A C nyelvben az enum és az int típus között oda-vissza létezik implicit kon- 
verzió. Ezzel szemben C-4-t-ban, ha enum típusra konvertálunk, ki kell írnunk 
a típuskonverziót. 

















8. fejezet: Típuskonvérzék 


A Cx-4-ban az enum típus felhasználásakor (a fenti kódrészletben a "-gal megje. 
Jölt sorokban) természetesen elhagyhatjuk az enum kulcsszót, mert az enum 
neve önmagában is típusértékű, de itt a C-vel való kompatibilitás miatt kiírtuk, 

A C automatikus konverziót biztosít a void" típusú pointer és tetszőleges 
típusú pointer között oda-vissza, a €434-ban ezt a konverziót is ki kell írnunk, 

A referenciára a következő szabályok érvényesek. Nem konstans referen. 
ciára nincs automatikus konverzió inkompatibilis típusok referenciáiról, Néz. 
zük meg az alábbi példát! 





Tudjuk, hogy az int és a double típusok között van automatikus típuskonver- 
zió. Referencia esetén azonban ugyanaz a helyzet, mint a pointereknél: a po- 
inter és a referencia is egy memóriacímet jelent. A pointerhez hasonlóan két 
típus kötődik hozzá: a referencia típusa, amelyet megadunk deklarációként, 
illetve az adott memóriaterületen található változó típusa. Ez nem meglepő, 
hiszen láttuk (7.2. Behelyettesíthetőség fejezet), hogy a referenciára is műkö- 
dik a polimorfizmus, amelynek előfeltétele ennek a két típusnak a szétválása. 
Vagyis, amikor egy int típusú változóval inicializáljuk a referenciát, a 
fordító hibát jelez, hiszen az int memóriareprezentációja eltér a double me- 
EREZZUK LEKÉTEN És az a kísérlet, hogy egy int-re jellemző memóriate- 
letet double-ként kezelünk, nagy valószínűséggel programozói hiba. Nem is 
szólva arról, hogy a sizeof(int) kisebb lehet, mint a sizeof(double), vagyis az 
EÁ a memóriában az m után következő változók értékét is elronthatja. 
második esetben az m változót konvertáljuk double típusúra. 
eredménye egy ideiglenes double érték, amely konstans, így nem adható át 
paraméterként olyan függvénynek, amely nem konstans referenciát vár. Ideig 


jenes értéket amúgy sem túl ésszerű változtatni, hiszen a változtatás után 





——————— — — EZAfeltesználőtítáesok konvérziől 


A harmadik esetben bemutatott , erőszakos" tí 31 i 
t rmadik . 9 ipuskonverzióval fordítá. 
időben mindig sikerrel járunk, vegyük például az alábbi típuskonverziót: s; 


7 AGÜGTEKTÖEZ TÁSNBTEKA EE ETSTSTE ENNE NEZ ZERO EZT ZZEZZE KTK] 


A 7.2. Behelyettesíthetőség fejezetben ismertetett inkompatibilis típusokkal 
már foglalkoztunk. Jelen esetben hibát követünk el: egy int típusú memória- 
területet double típusúként kezelünk. 

Az eddigi próbálkozásoknak nem volt sok értelme, és a fordító megpróbál- 
ta kiszűrni ezeket az eseteket, hiszen az értelmetlenség programozói hibára 
utal. Ha viszont értelmes dolgot szeretnénk csinálni, akkor abban a fordító is 
partner. A referenciát nemcsak akkor használjuk, ha meg akarjuk változtatni 
valaminek az értékét, hanem akkor is, ha meg akarjuk takarítani a függ- 
vényhívásból eredő másolást, amelyet a 4.1.3. Konstans függvényparaméterek 
fejezetben már említettünk. Ha csak ez a célunk, akkor megmondjuk a fordí- 
tónak, hogy nem szeretnénk megváltoztatni az átadott értéket, de nem akar- 
juk, hogy lemásolja. Ezért a referenciát konstansnak deklaráljuk. Ilyenkor a 
fordító ellenőrzi, hogy a típuskonverzió eredményeként létrejött ideiglenes 
konstans változót nem változtatjuk meg, és lehetővé teszi referencia szerinti 
átadását másolás nélkül. 





Természetesen a fenti példában a konstans referencia alkalmazásával nem 
nyertünk különösebb teljesítménynövekedést, de egy nagyobb objektum át- 
adása esetén jelentős másolási költséget takaríthatunk meg. 


8.2. A felhasználói típusok konverziói 


Ebben a részben az általunk írt osztályok típuskonverziós lehetőségeiről lesz 
szó. Ilyenkor két fontos esetet kell megkülönböztetnünk. Az egyik az öröklés 
szempontjából két független típus közti típuskonverzió, a másik esetben az 
öröklési hierarchia mentén végzünk típuskonverziót. 
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8. fejezet: Típuskonverziók 


8.2.1. Konverzió független típusok között 


A típustámogatás jegyében azt szeretnénk, hogy az általunk megírt osztálya. 
kat képesek legyünk olyan viselkedéssel felruházni, amilyenekkel a beépített 
típusok rendelkeznek. Tételezzük fel, hogy szeretnénk egy olyan String osz. 
tályt írni, amely a C-beli lehetőségeknél könnyebbé teszi a szöveges művele. 
teket. Az eddigiek alapján egyszerűen megírhatunk egy dinamikus karakter. 
sorozatot tartalmazó osztályt, és az összeadás operátor megfelelő túlterhelé. 
sével lehetőséget biztosíthatunk sztringek kényelmes összefűzésére. Ugyan. 
akkor szeretnénk, ha ez az osztály kompatibilis lenne az eddigi C függyé. 
nyekkel, ugyanis számos programozási felület C-ben íródott. A kompatibili. 
tást kétféle módon is szeretnénk megoldani: 


e Ha egy függvény nullterminált karaktertömböt ad vissza, akkor az 
automatikusan konvertálható legyen a String osztályra. Például, ha 
van egy függvényünk, amely String argumentumot vár, akkor ott át. 
adhassunk egy char " típusú, nullterminált, C stílusú sztringet. 


e Ha van egy String objektumunk, szeretnénk, hogy átadható legyen 
bárhol, ahol konstans C stílusú sztringet kell átadni. 


Erre a két problémára a Ct- két nyelvi elemet kíná!. Ha egy másik — esetleg 
beépített — típusról szeretnénk konvertálni a mi osztályunk típusára, a 
konverziós konstruktor jelent megoldást. Ha az osztályunkról szeret- 
nénk egy másik típusra konvertálni, akkor a konverziós operátor a meg- 
felelő eszköz. 


Feladat: Tervezzük meg és valósítsuk meg egy String osztály konverzióit! 


Az osztály adatreprezentációja alapvetően a karaktersorozatra mutató poin- 
ter és a karaktersorozat hossza. Ugyanakkor látni fogjuk, hogy egyszerűbb 
megírni a C stílusú sztringekkel való együttműködést biztosító operátort, ha 
a karaktersorozat végét egy NO" karakterrel lezárjuk, és azt mindig konzisz- 
tensen tartjuk. 











—F———, 52. hfeltasználóítápusok konverztői 


A konverziót a String típusra a konverziós konstruktor végzi. A konverziós 
konstruktor olyan egyparaméterű konstruktor, amelynek a paramétere olyan 
típusú, amilyen típusról konvertálni szeretnénk. Példánk esetében ez char ". 
Mivel a konverzió során nem változtatjuk meg a megadott paramétert, kons- 
tansnak deklaráljuk. 









ppatati] — strfil; 
) ENE 
ppatalelementsNum] - "90" 
h AV LARZT AVON 


Ezek után működőképessé válnak az alábbi kódrészletek: 


// Ez a konstrul 
String s1-" 
. // Az operator 
"String stri ly 






(0 // Az operatorsz szin 
.  Str1l 4- "James Bond 
Vagyis a konstruktornak van még egy funkciója, amelyet eddig nem ismertünk: 
képes konverziót végrehajtani. Az operátorok túlterhelésének tárgyalásánál 


(6. fejezet) adósak maradtunk még egy jelenség magyarázatával. A komplex 
számot megvalósító osztály konstruktorát az alábbi módon definiáltuk: 


"complex(double rez0, doúble"imz0jf/thisssre rejt thiszzim zám) 


Példaként kiragadva a szorzás alapműveletet adott az alábbi deklaráció, 
amely a Complex osztály egyik tagfüggvénye: 


" complex operator t(const Cfblex"EEhéőtHer) EGNSEÉLT Ess 
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8. fejezet: Típuskonverziók 


Azt állítottuk, hogy a fenti függvény és a konstruktor megírása együttesen 
eredményezi, hogy a (5-ti3)"2 műveletek is működni fognak, holott nem is ír- 
tunk Complex első paraméterű és double második paraméterű operátort. Mi. 
vel a konstruktor utolsó argaumentumának van egy alapértelmezett értéke, 
ezért ezt úgy is felfoghatjuk, hogy van egy 


7" comptex(double rejt thiszsrez ré; thisssim z OG) 


konstruktorunk is. Ez a konstruktor pedig képes a double Complex automa- 
tikus konverzióra. Felmerülhet a kérdés, hogy miért kellett viszont double el- 
ső paraméterrel globális operátorokat definiálni. A választ az operátorok túl- 
terhelésénél már említettük: túlterhelt operátorok esetén a fordító az első pa- 
ramétert használja arra, hogy kiválassza a megfelelő operátort egy adott kife- 
jezéshez. Ezért az első paraméterre operátorok túlterhelésénél nem beépített 
típusok esetén nincs automatikus konverzió. 

A hagyományos típuskonverziónak egyszerű a szintaxisa: a céltípus nevét 
kell a kifejezés elé írni: 





double d; eü 
d - Cint)3.14; 





String s; 32 3 a 
s - (String) "James Bond." 


Complex cp : 
c - (Complex)3; // doubil 





Ezzel a hagyományos szintaxissal csak az egyargumentumú konstruktort le- 
het használni. Ezért a C-- új szintaxist definiál, amely alkalmas a többar- 
gumentumú konstruktorral történő konverzióra: 





Így az utolsó példában lehetőségünk nyílt rá, hogy egy számpárt rendre valós 
és képzetes részként értelmezve komplex számmá alakítsunk. A fenti példák- 
ban a konstruktor — pontosabban a konstruktor által kijelölt konverzió — egy 
olyan típusú konstans ideiglenes értékkel tér vissza, amilyen típushoz a konst- 
ruktor tartozik. Jelen esetben a 3, 2 számpárt konvertáljuk Complex típussá. 
A String konstruktor egy ideiglenes konstans String típusú objektumot hozott 
létre, a Complex konstruktor pedig egy ideiglenes konstans Complex típusú ob- 
jektumot, Vagyis, ha a Complex osztály valamelyik tagfüggvényében leírjuk az 
alábbi kifejezést, akkor létrejön egy ideiglenes Complex típusú konstans objek- 
tum, majd mivel senki sem használja fel, felszabadul. Olyan, mintha egy érté- 
ket int típusra konvertálnánk, majd nem használnánk fel. 





ejülten di 8.2. A felhasználói típusok konverziói 


Ezért emeltük ki már a 3.4. K (onstruktorok és destruktorok feje GÜsa 
konstruktort nem lehet meghívni úgy, mint egy tagfügg fejezei HGBESL SÁR 
másképp viselkedik: most már látjuk, hogy ezt kon: pedi VESASB 6ja0 

Már említettük, hogy az egyargumentumú konstruktor által megvalósí. 
tott konverzió automatikus, nem feltétlenül kell kiírnunk: 


A fenti példában a konverziók mindegyike esetén létrejön egy konstans ideig- 
lenes sztring, majd az adódik át az — operátor paraméterének. 
Az ilyen jellegű konverziót általában függvényhívásban használjuk: 











Ugyanakkor, ha adott három osztályunk, A, B és C, ahol létezik az az A— B és 
a B5oC automatikus konverzió, a fordító a többlépéses konverziónál csak egy 
saját típust tartalmazó típuskonverziót hajt végre automatikusan, a többit ki 


kell írni: 





Sokszor szeretnénk elérni, hogy ne működjön az automatikus konverzió. A 3.5.2. 
részben bevezetett IntFifo esetén a 


DTNEFÁFOGÍN GÁZ ÉN ér ÁÁ KELME SZÉ NERTAGTOBAÁLKT ERKEL tért 51 eöztékékőT 


konstruktor nem konverziós célokat szolgál, csak inicializálásra szántuk. 
Ezért érthető, hogy nem szeretnénk, ha rejtélyes automatikus konverziók je- 
lennének meg az int és az IntFifo típusok között. Ezt az explicit kulcsszóval 
tilthatjuk meg, amelyet a konstruktor elé írunk. Ezt a kulcsszót az osztályde- 
finíción belül kell megadnunk. Ekkor az adott konstruktor által meghatáro- 
zott típuskonverzió csak explicit lehet, vagyis csak akkor működik, ha kiírjuk. 
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8. fejezet: Típuskonverziók 





Érdemes megjegyezni az alábbi két szintaktika közti különbséget: 





Nletve: 





A második kódrészlet implicit típuskonverziót ír elő int típusról IntFifo típus- 
ra, amelyet az int argumentumot váró, egyargumentumú konstruktor tudna 
elvégezni. Az explicit kulcsszó miatt az egyargumentumú konstruktor nem 
vehet részt implicit típuskonverzióban, vagyis fordítási hibát kapunk. 
Vizsgáljuk most meg a másik irányt! Hogyan tudunk a String osztályból 
const char?" típust készíteni? Erre való a konverziós operátor. Ahogy a neve 
sugallja, szintaxisa hasonló az operátorok túlterhelésének szintaxisához. 





A fő különbség annyi, hogy a konverziós operátorok esetén nem kell kiírni a 
visszatérési érték típusát, mert az operátor neve egyértelműen meghatározza. 
Ezeknek az operátoroknak természetesen nincsenek globális változataik, csak 
tagfüggvényként lehet őket deklarálni. Az operátorokhoz hasonlóan lehetnek 
virtuálisak és öröklődnek. Hasonlóan a konverziós konstruktorokhoz, auto- 
matikus típuskonverziót jelentenek, és csak egy saját típust is tartalmazó 
konverziós lépést képesek áthidalni, a többit expliciten ki kell írni. 

Mivel a példában mindig elhelyeztünk egy lezáró nulla karaktert a ka- 
raktersorozat végére, ez az operátor csak visszatér a karaktersorozatra muta- 
tó pointerrel. Jól látható a döntés oka, hogy miért csak a const char" operá- 
tort írtuk meg: a char" operátor lehetővé tenné, hogy a karaktereket tároló 
belső adatterületet inkonzisztenssé tegye valaki kívülről, amely ellenkezik az 
egységbe zárás alapelvével. Ha pedig lemásolnánk a területet egy dinamiku- 
san lefoglalt karaktertömbbe és egy erre mutató pointerrel térnénk vissza, 
akkor azt kockáztatnánk, hogy valaki elfelejti ezt felszabadítani. Így viszont 
csak attól kell óvni a felhasználókat, hogy ne tárolják el a visszaadott poin- 
tert, mert a String objektum működése közben érvénytelenné válhat. 
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áz EE 2 SÉKEL SSEL EGES HELYÉN 


A konverziók leggyakoribb problémája, hogy bizonyos kifejezések esetén 
több megoldás is létezik, és a fordító nem tud választani. A ölén esetekben 
hibaüzenetet ad. Vegyük például a String osztályunk alábbi felhasználását! 


A fenti példában a fordító nem tudja, hogy az — operátor bal oldalán álló 
Stringet konvertálja const char" pointerré, vagy a jobb oldalon álló sztringkons- 
tanst Stringgé. Az —— operátor ugyanis mindkét típusra értelmezve van: két 
const char" között, illetve két String között. 

Az első esetben az — operátor beépített operátor, és beépített operátor ese- 
tén az első paraméternél nincs szükség típusegyezésre, elég, ha van típuskon- 
verzió. Ezért expliciten meg kell mondanunk, melyiket szeretnénk használni: 


Ha a típuskonverziós útvonal nem egyértelmű, fordítási hibát jelent. Ezért ez 
a hibatípus inkább kellemetlen, mint veszélyes. 


PE DOS AZÉ MÁST at se EY ÉT ka EL s Sass ezét 
Útmutató: 
— Csak akkor írjunk konverziót, ha természetes. Sose erőltessük a konverziót! Például a 


Fifo-int konverziónak semmi alapja sincs, míg a String és C típusú sztring közötti kon- 
verzió természetes. 


— Nagyon vigyázzunk a védett (private, protected) tagváltozók kiadására konverziós ope- 
rátorok esetén, mert lehetőséget adhatunk objektumaink inkonzisztensé tételére (azál- 
tal, hogy nem konstans pointert vagy referenciát adunk ki a védett tagváltozókra)! Ha 
kiadjuk ezeket a tagváltozókat, konstansként tegyük, és írjuk elő az osztály felhasználó- 
inak, hogy ne tárolják el a kapott értéket! 


— Konverziós operátor helyett lehetőleg használjunk konverziós konstruktort! Az egységbe 
zárás alapelve miatt érdemesebb egy másik adatszerkezet alapján felépíteni az osztályt, 
mint kiadni az elrejtett tagváltozóit! 


— Mindig a csak a legszükségesebb konverziót írjuk meg, mert minél több a konverzió, an- 


nál valószínűbb a kétértelműség! 


8.2.2. Konverzió az öröklési hierarchia mentén 


Tekintsük most a leszármazottról szülőre történő típuskonverziót! Ha vissza- 
emlékezünk az előző fejezet Person-Employee példájára, akkor az objektumok 
közötti típuskonverziót az alábbi példával illusztrálhatjuk: 














8. fejezet: Típuskonverziók 








Vagy a fentiekben megismert konstruktorszintaktikával: 


"person p 2 PaFSGK(eMploy GJ TEMES TET 


A példa második fele jól illusztrálja, hogy itt konstruktor fog meghívódni, 
Felmerül a kérdés, hogy melyik konstruktor. A válasz a másolókonstruktor, 
hiszen a behelyettesíthetőség elve miatt a Person$ típusú paraméter esetén 
megadhatunk Employee típusú objektumot."§ A másolókonstruktor viszont 
csak az ősosztály résszel , foglalkozik", így az employee változó , alja" nem má. 
solódik át, elveszik a konverzió során. 


Employee employee; (Personjemployee; 






Person li Person 


birthYear 
employmentYear 


Empajes 





levágva") 4 


27. ábra. Szeletelés kapásból 


A C--- élénk fantáziájú úttörői ezt a konverzió közben történő jelenséget , sze- 
letelés kapásból" (slicing-on-the-fly) névvel illették. Szigorú értelemben vett 
szeletelésről persze szó sincs. Az eredeti, konvertált objektum megmarad, 
mindössze a konverzió során nem másolódik át egy rész, bár az új objektum 
kétségkívül úgy néz ki, mintha a réginek levágták volna az alját. Mindezt a 
fenti ábra szemlélteti. Mivel másolókonstruktor mindig van (emlékezzünk 
vissza, hogy ha nem írunk, akkor a fordító biztosít egy sekély másolatot ké- 
szítő másolókonstruktort), ez a típusú konverzió szükség esetén automatiku- 
san is végbemegy. 


Utmutató: Kezdő Cs-programozók gyakori hibája, hogy objektumokon keresztül akarnak po- 


tímorf viselkedést elérni, holott az csak pointeren vagy referencián keresztül működik. Az előző 
fejezet alakzatos példáját felhasználva — egy pillanatra visszatérve a példa elejéhez, ahol a 
Shape nem absztrakt osztály — tételezzük fel, hogy valaki létrehoz egy Shape shapes[ 3]; töm- 
böt, és feltölti különféle típusú (Circle, Rectangle) elemekkel. A program másik pontján kivéve 
az elemeket azt tapasztaljuk, hogy nemhogy a virtuális függvények nem működnek, de a 
tömbben sem tárolódtak el az egyes leszármazott típusokra jellemző elemek, amelyek a Shape 
ősosztályban nem szerepeltek. A tömb ugyanis nem Shape típusra mutató pointer típusú volt, 
hanem Shape típusú, és amikor betettünk egy Rectangle típusú objektumot, a konverzió miatt 
csak a téglalap objektum Shape része másolódott át, a többi , le lett vágva". Ne feledjük: po- 
limorf viselkedést csak pointeren és referencián keresztül várhatunk! 





56 FiizgokösSak az z BÁN hogy a Person osztálynak van olyan konstruktora, amely 
mployee vagy Employeeg: paramétert vár. Ezt azonban a f. ó kö ivatkozás miatt 
nem engedi, és fordítási idejű hibát kapunk. DES tznyáteszg 
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8.3. A Cs típuskonverziós operátorai 


A szülőről a leszármazottra nincs ilyen jellegű típuskonverzió, ha szükségünk 
van rá, a leszármazottban konverziós konstruktort kell írnunk. 

Pointer és referencia esetén a leszármazottról a szülőre történő automati- 
kus típuskonverzió már jól ismert a 7. fejezetből: ez jelenti a behelyettesíthe- 
tőség megvalósítását. Az ellenkező irány nagyon veszélyes: ha az adott poin- 
ter, illetve referencia mögött nem olyan leszármazott van, amire konvertá- 
lunk, a viselkedés durva futási idejű hiba lesz (a program a saját memóriate- 
rületén kívülre írhat). Ez legtöbbször azt vonja maga után, hogy az operációs 
rendszer leállítja a programot. 

Többszörös öröklés esetén további problémák merülnek fel a hierarchia 
mentén történő típuskonverzióval. Itt vagy elkerüljük a 7.4. Többszörös öröklés 
fejezetben tárgyalt tiltott konverziókat, vagy felhasználjuk a 8.3., következő 
részben említendő dynamic cast operátort. 


8.3. A Cs típuskonverziós operátorai 


Az explicit típuskonverziót C nyelven a kifejezés elé 0 zárójelek közé írt új tí- 
pus megadásával definiálhatjuk. Például: 


ONAVTKESÁZEN WZ ESÉTENEG NÉ BÁTBESZ TTL EZETBE 


Ezt a típuskonverziót használjuk például pointerek között, egészek között, a 
konstans változókat ezzel konvertáljuk nem konstanssá. A nagyobb biztonság 
és átláthatóság érdekében a C-t- saját konverziós operátorokat definiál, ame- 
lyek jobban kifejezik a típuskonverzió jelentését. A C megoldás ugyanis egy 
kalap alá vesz bizonyos konverziós szándékokat. Jobb lenne, ha pontosabban 
meg tudnánk adni a konverzió célját. Ezeket a Cr nyelvben az alábbi operá- 


torok segítik: 





e — static cast (statikus típuskonverzió) 
e — const cast (konstans típuskonverzió) 
e — dynamic cast (dinamikus típuskonverzió) 


e  reinterpret cast (újraértelmező típuskonverzió) 


Ezek az operátorok a 2. precedenciaszinten (,A" függelék) helyezkednek el. 
Szintaxisuk az alábbi: 
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8. fejezet: Típuskonverziók 
A C stílusú típuskonverzió helyett leggyakrabban a statikus típuskonver. 
ziót használjuk. Vagyis, ha lefelé kerekítés végett eddig azt írtuk, hogy 


a Ct4-ban ez az alábbi formát ölti: 


Ősosztály típusú mutatóról leszármazott típusú mutatóra is ezt a konverziós 
operátort használjuk, ha biztosak vagyunk a konverzióban. Ha nem ez a 
helyzet, akkor a későbbiekben tárgyalandó dynamic. cast operátor futási idő. 
ben megállapítja, hogy helyes-e a konverzió, és csak akkor hajtja végre. 

A statikus típuskonverziónak megmaradtak azok a megkötései, amely a C 
stílusú elődjének (például struktúrát nem konvertálhat egész típussá), vala- 
mint nem konvertálhat konstans típust nem konstans típussá, ekkor fordítási 
idejű hibát kapunk. Erre ugyanis egy kifejezetten erre a célra létrehozott tí. 
puskonverziós operátor áll rendelkezésünkre. 

A konstans típuskonverzió képes egyedül konstans típust nem kons- 
tanssá tenni, illetve volatile típust nem azzá. Ez ugyanis olyan veszélyes mű- 
velet, amelyet külön át kell gondolni, és feltűnően megjelölni a kódban. Egyéb 
konverziókra (például int-double, ős-leszármazott) nem alkalmazható. Más 
C4-4- konverziós operátor nem képes végrehajtani ezt a konverziót. Példaként 
tekintsük meg az alábbi függvényt, amely egy vásárolt osztálykönyvtár része, 
és nincs jogunkban módosítani a forráskódját. 





Ez a függvény egy ismeretlen formátumú állományhoz adja a változót. Mivel 
mentésről van szó, a buff változót konstansként kellett volna definiálni. Így 
ha ki szeretnénk írni egy konstans tagváltozót, mert az állomány formátuma 
előírja, akkor típuskonverzióhoz kell folyamodnunk, amely nem konstanssá 


teszi az elmentendő változót. C-t nyelven erre az alábbi kódrészlet a legmeg- 
felelőbb megoldás: 
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8.3. A Cs típuskonverziós operátorai 
ZZKEKEGGG TES E KTNTKOSEHEE ÜT e egerek te tanty Bert visznhcázra szadi 


A dinamikus típuskonverzió szintén speciális típuskonverziót valósít meg: 
az öröklési hierarchián lefelé (leszármazottra) történő konverziókhoz szüksé. 
ges. Az osztályoknak polimorfoknak kell lenniük, azaz a konvertálandó tí- 
pusnak legalább egy virtuális függvényt kell tartalmaznia. Mivel futási idő- 
ben ellenőrzi, hogy tényleg végrehajtható-e e típuskonverzió, használatához a 
futásidejű típusinformációk kezelését be kell kapcsolnunk a fordításkor. Ezen 
típusinformáció segítségével a keresztbe konverziót is megoldja többszörös 
öröklés esetén, vagyis biztonságos (ekkor szükséges legalább egy virtuális 
tagfüggvény az ősosztályban). Ha a kívánt konverzió nem sikerül, az operátor 
bad cast szabványos kivételt dob (lásd 10.2.2. Kivételhierarchiák fejezet). 
Privát öröklésnél nem használható az osztályhierarchián felfelé való konver- 
zióra, mert futási idejű hibát kapunk. 

Az újraértelmező típuskonverzió az implementációfüggő konverziók 
esetén használható. Általában pointerre alkalmazzuk, amikor lényegében 
csak a pointer típusát változtatjuk, vagyis azt, hogy milyen műveletek értel- 
mezhetők egy memóriaterületen (, újraértelmezzük" az ott található biteket). 
Ezért hatása sokszor fordítófüggő. Mivel az egész típusok és a pointerek mé- 
rete fordítófüggő, ezért az egész típusok és a pointerek közötti konverziók ese- 
tén is ezt az operátort használjuk. Privát öröklésnél az ősosztály típusú poin- 
terre szintén ezt az operátort használhatjuk. A 7.2. Behelyettesíthetőség feje- 
zet Sguare osztályt bevezető példája a következőképpen írható át: 





Ugyanakkor konstans típust nem konstanssá ez az operátor sem képes át- 
konvertálni. 

Bármennyire is hasonlít a függvényhíváshoz a konverziós operátorok 
szintaktikája, nem függvényhívás, mivel ezeknek az operátoroknak csak egy 
argumentumuk lehet. Vagyis visszatérve a Complex osztályhoz (6.3. Példa: 
egy komplex számokat megvalósító osztály fejezet) az alábbi sor 





nem a 2-i3 kifejezést adja, hanem a 3-i0-t, a vessző ugyanis nem az argu- 
mentumlistában szereplő vessző, hanem a vessző operátor, amely egy kifeje- 
zéssé kombinálja a két argumentumot, és visszatérési értéke a második ar- 
gumentum. Ez azt jelenti, hogy a 


TGTKCOKÁPLEKEB) TSZ ZÁST ÁRANNTENNKNBE SE KEY ETVS ERÉNYT KEZET] 


ifej jtódi zándékunk, hogy a 
kifejezéssel egyenértékű művelet hajtódik végre. Ha az a s: ó 7 
2-i3 kifejezést állítsuk elő, akkor továbbra is a konstruktorszintaktikát al- 
kalmazzuk: 


EGE DK CZB) ::./IZHNGKKÁLZESÁENBÁN RÁNK SARA KEK AGNÁESES ESEOS TS ZGST] 

















21 sin eZedát; const cast, reinterpret 


SS dynamic. cast egyedülálló: feladatát a többi ezi 
operátor nem képes ellátni, viszont ennek az az ára, hogy futásidejű tmsin. 
fokeTAStÁSESASEBÉLÉS d kérdézeségeklássítjak programunkat. 





- JÁLESTÉKK ESŐ rgétértütajet, mindig a konstruktorszintaxist alkalmazzuk! 
— C stílusú konverzió helyett használjuk a leginkább odaillő Cs: konverziós operátort! 


— A dinamikus típuskonverziót lehetőleg kerüljük el: alkalmazzuk például a 7.2. Behelyet. 
tesíthetőség fejezet végén leírt módszerek valamelyikét. 








KILENCEDIK FEJEZET 


Névterek 


Egy függvény vagy osztály írásakor könnyen előfordulhat, hogy az általunk 
választott név ütközik egy meglevővel. Különösen igaz ez, ha más fejlesztők 
kódját is felhasználjuk. A problémára a megoldást a névterek (namespace) 
alkalmazása jelenti. A névterek felhasználásával a különböző (függvény, osz- 
tály, típus (typedef), globális változó és konstans) definíciók névhierarchiába 
szervezhetők. Így nem csak a névütközés kerülhető el, de megvalósítható a 
definíciók logikai csoportosítása is (például matematikai rutinok, hálózatke- 
zelés, rajzolás stb.). Ez természetesen akkor nyer igazán létjogosultságot, ha 
több fejlesztő nagyobb projekten dolgozik. A névterekkel tetszőleges mélységű 
névtér-hierarchia alakítható ki. 


9.1. Bevezetés a névterek használatába 


Tekintsük meg az alábbi névtér-definíciókat: 




















9. fejezet: Névterek 





Névtér-definíciót a namespace kulcsszóval kell kezdeni, ezt követően kell 
megadni a névtér nevét, majd ( ) között a névtérbe tartozó definíciókat. 

A példában a String osztály a Lib és a Common névtérben is definiált, de 
ez nem okoz névütközést, hiszen a tartalmazó névtér különböző. A sort függ- 
vény definíciója beágyazott névtér-definícióra mutat példát: a Math névtér 
tartalmaz egy Algorithms névteret, a sort pedig ebben definiált. 

A névterekben levő definíciók felhasználása során a :: hatókör operátor 
felhasználásával meg kell adni a teljes , elérési utat", vagyis a definíció minő. 
sített nevét (gualified name). Erre a main függvényben látunk példákat. 
Amennyiben egy névtérből több definíciót is fel kívánunk használni, körül- 
ményes minden esetben a névtér megadása. Ekkor a using namespace név- 
térnév direktívával a névtérben levő definíciókat az adott deklarációs ré- 
gióban (declaration region) közvetlenül elérhetővé tehetjük. Mielőtt a dekla- 
rációs régió fogalmát pontosan meghatároznánk, az előző példában definiált 
névterek felhasználásával illusztráljuk a using namespace használatát: 





,A javasolt kódszervezést (osztálydefiníciók .h fejléc, defi- 
níciója .epp forrásfáj akban) köveéve felmazüf ő késés, égést using name- 
space-t a fejléc, vagy pedig a forrásfájlba tegyük. Az irányelv a következő: 





9.1. Bevezetés a névterek használatába 





SZETT — 
Útmutató: Kerüljük a using namespace fejlécfájlokban való alkalmazását. Ex) 
felette ENNE ZNEEESSZ ze ———.d—.tktk zizi RŐ 


A using namespace fejlécfájlokban való alkalmazásával a következő a problé- 
ma. Soha nem tudhatjuk előre, hogy az adott fejlécfájl mely forrásfájlokba kerül 
utólag az include alkalmazásával. Az include által közvetve beágyazott using 
namespace következtében az adott forrásfájlban a névtérben levő definíciók 
közvetlenül elérhetővé válnak, ami nem várt névütközésekhez vezethet. 

Mint említettük, a using namespace hatása az adott deklarációs régió- 
ra terjed ki. Ezt könnyű megjegyezni: képzeljünk a using namespace helyébe 
egy változó deklarációt, s ahonnan ez a változó elérhető, ott a using name- 
space is érvényben van. Ez globálisan alkalmazott using namespace esetében 
a deklaráció sorától a forrásfájl végéig, lokálisan (egy adott függvényen belül) 
alkalmazva pedig a függvénytörzs lezárásáig () zárójelig) terjed ki. 

Egy névtérbe tetszőleges számú fájlban , tehetünk" definíciókat. A kód fej- 
léc és forrásfájlokba szervezése tisztán a forráskódmenedzsment kérdése, 
a definíciók névterekbe szervezésével ettől függetlenül alakítható ki a definí- 
ciók logikai csoportosítása. 

Ha egy névtérbe több fájlban is teszünk definíciókat, akkor a felhasználás 
során csak azok a névtérbeli elemek érhetők el, amelyeket deklarálunk: ez 
számunkra általában azt jelenti, hogy a megfelelő definíciókat/deklarációkat 
tartalmazó fejlécfájlokat include-olnunk kell. Nézzünk erre egy példát: 





181 














9.2. A globális hatókör elérése 


Tekintsük az alábbi kódrészletet: 





Az f függvény a Lib névtérben található. Ennek első sorában a String típus- 
hivatkozás a Lib névtérben levő String definíciót jelenti. A globális String 
osztály eléréséhez a :: hatókör operátort a típus neve elé kell írni: 


FETETTÉZEÁNTAK ÖT ÖREGET ZS GE VGGGNÁ CSS TÜLKZNY 011072 -0A[70Ő EBREN 


A hatókör operátor ebben a formában bármilyen esetben felhasználható, 
amikor egyértelművé kívánjuk tenni, hogy az adott definíció a globális ható- 
körre vonatkozik, vagy csak a kódunkat szeretnénk kifejezőbbé tenni. 


9.3. Tagfüggvények definiálása 


Amennyiben az ajánlást követve az osztálydefiníciót fejlécfájlba, a tagfüggvé- 
nyek definícióit forrásfájlba tesszük, a tagfüggvény-definíciók többféle módon 
is megadhatók, Nézzük meg az alábbi osztálydefiníciót: 

















Alternatív megoldásként használhatjuk a using namespace utasítást a forrás- 
fájlban: 


A következő megoldás is megfelelő, bár több tagfüggvény esetén körülménye- 
sebb a használata: 


9.4. Using deklarációk 


A using namespace lehetővé teszi a névtérben található valamennyi definíció 
közvetlen elérését. A using önmagában is használható a névtérben levő egye- 
di nevek közvetlenül elérhetővé tételéhez. A using ezen használatát using 
deklarációnak nevezzük. Alkalmazását az alábbi példa szemlélteti: 
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9. fejezet: Névterek 





Az f függvény az NA és NB névterekben is definiált. A using NA::f; sor az NA 
névtérből az f függvényt (és csak ezt) az adott deklarálási régióban közvetle- 
nül elérhetővé teszi. Így a main függvény első sorában az / az NA::f függvényt 
jelenti. Az ezt követő sorban a using NB::f; utasítással az f szimbólum jelenté- 
sét az adott deklarálási régióra felüldefiniáljuk, így az utolsó sorban f az 
NB::f függvényt jelenti. 


9.5. Argumentumfüggő névfeloldás 


Az argumentumfüggő (Koenig) névfeloldás (Koenig lookup) lényegét egy 
példán keresztül világítjuk meg. 





Az NS névtérben egy X nevű struktúrát és egy X£ paraméterrel rendelkező, f 
nevű függvényt definiáltunk. A main függvény második sorában az / függ- 
vényt minősített nevével, az utolsó sorában pedig közvetlen névmegadással 
használjuk. Az utolsó sornak fordítási hibát kellene eredményeznie, hiszen az 
f függvényt nem tettük a using namespace vagy a using használatával közvet- 
lenül elérhetővé. A C-t nyelv által támogatott argumentumfüggő névfelol- 
dásnak köszönhetően azonban az f függvénynév minősítés nélkül is használ- 
ható, mert az x paramétere az NS névtérben definiált, így az f szimbólum fel- 
oldásakor a fordító az NS névtérben is végez keresést. 





9.6. Névtér alias 
Az argumentumfüggő névfeloldás előnyei az operátorok használatak. 
válnak nyilvánvalóvá. Próbáljunk a szabványos kimenetre írni a cout objek. 


tum használatával a using namespace std; alkalmazása nélkül. A megoldás a 
következő: 





Az std::cout S£ "abc"; sor csak az argamentumfüggő névfeloldásnak köszönhe- 
tően fordul le. A cout az std névtérben definiált ostream típusú globális objek- 
tum, az c£ operátor szintén az std névtérben definiált globális függvény. Ve- 
gyük észre, hogy sehol sem adtuk meg minősítéssel (és a használt formában 
nem is tudnánk megadni), hogy az cc operátort az std névtérből kívánjuk 
használni! Az operátor cout argamentumára vonatkozóan viszont megadtuk, 
így az argumentumfüggő névfeloldásnak köszönhetően ez a forma is használ- 
ható. Érdemes megnézni, hogy az argumentumfüggő névfeloldás hiányában 
milyen formában kellene (a using namespace std használatától eltekintve) 
megadni a fenti kifejezést: 





Az argamentumfüggő névfeloldást a régebbi fordítók jellemzően nem támogatják. 


9.6. Névtér alias 


Ritkán, de előfordulhat, hogy egy hosszú névtérnév, illetve hosszú, egymásba 
ágyazott névtérnevek helyett egy rövid nevet kívánunk bevezetni. Erre van mód 
a namespace új-névtérnév - meglevő-hosszú-névtérnév alkalmazásával. Például: 
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TIZEDIK FEJEZET 


Kivételkezelés 


A program futása során a hibás esetek kezelése (például egy fájl megnyitása 
nem sikerült) a C nyelvben jellemzően a függvények által visszaadott hibakó- 
dok vagy egy globális változóban az utolsó hibára vonatkozóan nyilvántartott 
hibakód alapján történik. A C4- nyelvben a kivételek (exception) alkalmazá- 
sával ennél sokkal strukturáltabb, átláthatóbb és könnyebben karbantartha- 
tó hibakezelési alternatíva áll rendelkezésünkre. A fejezetben először érzékel- 
tetjük a hagyományos hibakezelés problémáit, majd ennek tükrében ismertet- 
jük a kivétel alapú megoldás szintaktikáját és mechanizmusát. Ezt követően 
bemutatunk néhány a gyakorlatban gyakran felmerülő szituációt, és ismer- 
tetjük a megoldást jelentő kivételkezelési technikákat. Ha ugyanis a kivéte- 
lek használatakor nem megfelelő körültekintéssel járunk el, az könnyen ve- 
zethet nem várt működéshez, például dinamikus memória használata esetén 
memóriaszivárgáshoz. 


10.1. A kivételek használatának alapjai 


10.1.1. Hagyományos hibakezelés 


A következőkben egy a hibás esetek kezelésére jellemző klasszikus megoldást 
vázolunk. Az egyszerűség kedvéért tegyük fel, hogy a main függvényből hív- 
juk a Wrap függvényt, a Wrap-ből a Save-et, a Save-ből pedig a ValidateAnd- 
Prepare és a DoSave függvényt. A hívási lánc ennek megfelelően a következő: 


main() Wrap() 2 Save() ? ValidateAndPrepare(), DoSave 0 


Ha a hívási lánc mélyén a DoSave, ValidateAndPrepare stb. függvényekben 
hibát fedezünk fel (például nem sikerült megnyitni a fájlt, vagy érvénytelen 
az egyik megkapott függvényparaméter), és a hibát nem tudjuk helyben ke- 
zelni, akkor ezt a hívó függvény (Save) számára a visszatérési értékben meg- 
adott, a hibára jellemző hibakóddal jelezzük."7 A Save függvényben meg kell 
vizsgálni a ValidateAndPrepare és a DoSave által visszaadott hibakódot, és 
értékének függvényében kell kezelni. Ha a hibát a Save függvényben sem 
tudjuk vagy akarjuk kezelni — mert például csak a legkülső main függvény- 





tárolni az utolsó hibakódot, bár többszálú kör- 


s" Lehetőség van egy globális változóban is fs 
ényel: ez esetben a hibakódot szálanként kell 


nyezetben ez kifinomultabb megoldást íg 
nyilvántartani. 














10. fejezet: Kivételkezelés 


ben célszerű megtenni —, akkor ezt szintén egy visszaadott hibakód formájá. 
ban jelezhetjük a hívó Wrap függvénynek. Ugyanez a gondolatmenet érvényeg 
a hívási lánc bármely szintjén levő függvényre. Az alábbi kódrészlet a fenti 
példát illusztrálja: 





ses Wünste 
int errorcode - Save(); 
if (errorcode !z ErrorCodes: :ERROR-OK) // A hívó keze" 












55 A hiba igény szerint helyben is kezelhető. i á 
ló Ly ető. Ha az ej hibákat eltérően kell kezelni, egy 
switch-case szerkezetben az errorCode OÁRÁZ AKA Los sznob 
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10.1. A kivételek használatának alapjai 





A példában valamennyi hibás esetet a main függvényben kezeltük. A hibakó- 
dok használatára épülő megoldás számos hátránnyal jár: 


e — Körülményes a hívási lánc minden szintjén ellenőrizni a visszaadott 
hibakódot. 


e A funkcionalitás és a hibás eseteket kezelő kód keveredik. A példában 
ez a Save függvényben szembetűnő. 


e Nem vagyunk rákényszerítve a hibás esetek kezelésére. Ha a függvé- 
nyek visszatérési értékét figyelmen kívül hagyjuk (figyelmetlenségből 
vagy lustaságból), akkor hiba esetén ugyanúgy dolgozunk tovább, 
mintha mi sem történt volna. Ez a lehető legrosszabb, mivel a hiba 
rejtett módon dolgozik tovább, és csak nagyon nehezen fogunk rájönni, 
miért nem a várt módon működik az alkalmazás. 


A C--4- nyelvben a kivételek alkalmazása nyújt megoldást a fenti problémákra. 


10.1.2. A kivételkezelés alapjai 


A kivételkezelés (exception handling) olyan mechanizmus, amely biztosítja, 
hogy ha hibát detektálunk valahol, akkor a futás , azonnal" a hibakezelő ágon 
folytatódjon. A kivételkezelést azonban nem véletlenül hívják kivétel-, és 
nem hibakezelésnek. A megoldás nemcsak hiba, hanem bármilyen , kivételes" 
helyzet esetén használható. 
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10. fejezet: Kívételkezelés 


A pontosabb megfogalmazás ennek megfelelően: a kivételkezelés mecha- 
nizmusa azt biztosítja, hogy kivétel esetén a futás azonnal a kivételkezelőre 
ugorjon. 

Először a teljességre törekvés igénye nélkül bemutatjuk a kivételkezelés 
néhány fontos aspektusát. 





Feladat: Kérjünk be a felhasználótól egy számot, és írjuk a szabványos kimenetre a recipro- 
kát. Ha a felhasználó érvénytelen bemenetként nullát ad meg, akkor jelezzük a hibát, és írjuk 
ki a hiba szövegét a szabványos kimenetre. A kivételkezelésre épülő megoldás a következő: 





A kimenet, ha a felhasználó érvényes bemenetet (nem nullát) ad meg: 





A kimenet, ha a felhasználó érvénytelen bemenetet (nullát) ad meg: 


A kódunkban a main függvényben egy try-catch blokkot találunk, egy 
catch ággal. A try védett blokkba f) közé írtuk be a normál működés kódját, 
illetve a catch ágba (j közé a hibakezelő kódot. Most nézzük, meg mi történik 
normál esetben, illetve akkor, ha hibát fedezünk fel. 
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10.1. A kivételek használatának alapjai 
a) Ha a védett blokkban nem találunk hibát (esetünkben érvényes a be- 
menet), akkor a () közötti védett blokk valamennyi utasítása lefut, ezt 
követően a vezérlés a catch ág (illetve ágak, mert mint látni fogjuk, 
több catch ág megadása is lehetséges) után folytatódik. Ennek megfe- 
lelően a megadott szám reciprokának kiírása után a , Done." szöveget 
írjuk ki. Mivel a catch ágak tartalma a hibás esetek kezelését szolgál- 

ja, normál esetben a bennük levő kód nem fut le. 


b) Ha a védett blokkban hibás feltételt detektálunk (esetünkben a be- 
menet érvénytelen), akkor a throw kulcsszóval kivételt (exception) 
dobunk. A throw utasításnak egy paramétert is megadunk, ez lesz a 
dobott kivétel. Esetünkben ez egy const char" típusú, "The number 
can not be zero." tartalmú sztring. A throw hatására a vezérlés azon- 
nal egy olyan catch ágra kerül, melynek paramétere kompatibilis a 
dobott kivétellel. Ekkor azt mondjuk, hogy az adott catch ág elkapja 
a dobott kivételt. Esetünkben a dobott kivétel const char" típusú, 
catch águnk paramétere is ilyen típusú kivételt vár, így a dobott kivé- 
tel elkapása megtörténik. A kivétel elkapásakor a kivétel beíródik a 
catch paraméterébe (esetünkben az exc nevű paraméterbe), és lefut a 
catch törzse, vagyis a catchhez tartozó () közötti kód. A catch törzsé- 
ben az elkapott kivétel hozzáférhető: példánkban ezt ki is használjuk, 
kiírjuk az elkapott kivételszöveget a kimenetre. Amikor a catch törzse 
lefutott, a vezérlés a try-catch blokk utáni következő sorra kerül (vagyis 
nem ugrik vissza a try-catch blokk belsejébe a kivétel dobását követő 
sorra). Példánkban ez a várt kimenetet eredményezi: a throw hatására 
lefut a hibakezelő catch ág, ebben kiírjuk a hibaüzenetet, majd a 
, Done." szöveget. A reciprokképző sor így nem fut le, de ez baj is lenne, 
mert nullával történő osztást eredményezne. 


Az előző példából nem derül ki, milyen előnyei vannak a kivételkezelésnek a 
hagyományos, hibakód alapú megoldáshoz képest. Ehhez az alábbiakban egy 
összetettebb példát tekintünk át, amely megmutatja a kivételkezelés egyik 
legfontosabb jellemzőjét: ha egy védett try blokkban függvényeket hívunk, 
akkor a hívási láncban akármilyen mélyen dobunk is kivételt, a vezérlés 
azonnal a hibakezelő catch ágon folytatódik. 


FEST BSE S ZS ESA SL ZELÉT SL BENE SE TET SE VETÉS et. gates les 
Feladat: induljunk most ki az előző fejezetben bemutatott példából, de a hibás esetek keze- 
lését kivételkezeléssel oldjuk meg! Tegyük fel, hogy bármilyen mélyen is detektáljuk a hibát a 
hívási láncban, a legmagasabb szinten, a main függvényben kívánjuk kezelni. 
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10. fejezet: Kivételkezelés 





static const int ERROR INVALID. PARAMETER - 1; 
static const int ERROR NULL. PARAMETER - 2; 


pi 
int mainO 
try 
wrapO; 
catch (const chart errorText) 
( 


cerr cc "Error! The error message is: 
cc errorText cc endi; 


cc endi 


catchCint errorcode) 
( 


cerr cc "Error! The error code is: " cc errorCode cc endi; 


J 
cout cc "This will be printed in all cases.": 


J 
void wrapO) ( ...; SaveO; ... 3) 


void Save0) 
1 
FILE? file - fopen("data2", "wr"); 
if (file —— NULL) 
throw "could not open file data2!"; 


validateandPrepare(pData, count); // A ppata és count 


// megfelelő lokális változók. 


DoSave(file, pData, count); 
fclose(file); // Ez így nincs rendben, majd visszatérünk rá. 


hi 
void validateandPrepare(int" pDpata, int count) 
if (ppata -— NULL) 
throw Errorcodes : : ERROR NULL. PARAMETER; 
if (count c 0) 
throw ErrorCodes::ERROR INVALID. PARAMETER; 


":.. // Hasznos logika, adatok előkészítése. 


Void DoSave(FILEt file, intt ppata, int count)( ...) 
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10.1. A kivételek használatának alapjai 


Az alábbiakban pontokba szedve összefoglaljuk a kivételkezelés mechanizmu- 


sának alapjait, az átláthatóság érdekében megismételve a bevezetőben már 
megszerzett ismereteket: 


s — A fenti kódban a main függvényben egy try-catch blokkot találunk, 
két catch ággal. A try védett blokkban a § közé írtuk be a normál 
működés kódját: ez esetünkben a Wrap függvény hívásából áll. 


s Ha a try által védett blokkban valamelyik hívott függvényben hibás 
feltételt detektálunk, akkor a throw kulcsszóval kivételt (exception) 
dobunk. A thrownak legtöbbször megadunk egy paramétert (a throw 
némiképp más szerepben paraméter nélkül is használható, erről ké- 
sőbb lesz szó), amely lehet egyszerű beépített típusú kifejezés, vagy 
akár egy adott osztálybeli objektum. Ezt a paramétert szokás kivé- 
telobjektumnak (exception object) is nevezni. A példánkban a Save 
függvény egy const char" típusú kivételt, a ValidateAndPrepare függ- 
vény pedig két esetbén const int típusú kivételt dob. 


e A throw használata sokban hasonlít a return utasításéhoz. A throw 
alkalmazásakor azonban nem a hívóhoz térünk vissza, hanem addig 
ugrik felfelé a hívási láncban a vezérlés, amíg egy megfelelő try-catch 
blokk el nem kapja. 


e A wctry-catch blokk akkor kap el egy kivételt, ha a van olyan catch ága, 
amelynél a paraméter típusa kompatibilis5? (például pontosan meg- 
egyezik) a dobott kivétel típusával. Az illesztés a catch ágak definiálá- 
si sorrendjében történik. A catch(...) minden kivételt elkap. 


e Ha egy catch ág elkapja a kivételt, a dobott kivétel beíródik a catch 
paraméterébe, a futás pedig az adott catch ágban folytatódik. A catch 
ágon belül a catch paramétere elérhető. A catch ágból kilépve a többi 
catch ág illesztése már nem megy végbe, a futás a kivételt elkapó try- 
catch blokk után folytatódik, vagyis nem történik visszalépés a throw 
utáni utasításra. 

s Ha egy kivételt nem kapunk el, akkor kezeletlen kivételnek számít. 
Ez esetben a könyvtári terminate függvény hívódik meg, ami alapér- 
telmezésben az abort függvényt hívja meg, ami pedig az alkalmazás- 
ból való kilépést eredményezi. Amennyiben ez számunkra nem megfe- 
lelő, a set terminate függvénnyel saját, a kezeletlen kivételek esetén 
hívandó rutin is megadható. 


Gyakorlásképpen nézzünk néhány esetet a fenti példa felhasználásával. 





"9 A kivételek illesztésére érvényes típuskompatibilitás nem egyezik "meg teljesen a behelyet- 
tesíthetőségre vonatkozó típuskompatibilitással, a definíciójára rövidesen visszatérünk. 
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1. A ValidateAndPrepare függvény pData paramétere NULL 


Ez esetünkben érvénytelennek számít, amit a megfelelő hibakód dobásával 
jelzünk: 





A throw paramétere ilyenkor egy const int típusú hibakód, A throw hatására 
addig lépünk felfelé a hívási láncban, amíg egy olyan try-catch blokkot talá. 
lunk, amelynek van egy int (vagy const int, intő, const int$-) paramétere, 
A kivételt a catch(...) is elkapná. Példánkban a hívási láncban legközelebb a 
main függvényben találunk try-catch blokkot (több nincs is), ezek catch ágai. 
nak illesztése történik meg a blokkok sorrendjében. Az első catch blokk pa- 
ramétere const char", ez nem kompatibilis a dobott kivétel int típusával, így 
ez a catch ág nem kapja el a kivételt. A következő catch ág paramétere int tí. 
pusú, így a dobott kivételt elkapja, a dobott hibakód beíródik az errorCode 
catch paraméterbe. A catch ág kódja lefut, ebben az igényeknek megfelelően 
kezeljük a kivételt: a példánkban egyszerűen kiírjuk a hibakimenetre a pa- 
raméterben megkapott hibakódot: 





Ezt követően a futás a main függvényben a try-catch blokk után folytatódik 
(cout cs " This will be printed in all cases."; sor). 
2. A ValidateAndPrepare függvény count paramétere kisebb 0-nál 


Ez esetünkben érvénytelennek számít, amit egy ERROR NULL PARAMETER 
hibakód kivételként dobásával jelzünk. Ennek típusa az előző esettel megegye: 
zően int, így kezelése is azonos módon történik. 

3. A Save függvényben a fájl megnyitása nem sikerül 


Ha nem sikerült megnyitni a fájlt, az fopen NULL pointerrel tér vissza. Ezt 
az esetet detektálva is kivételt dobunk: 


A dobott kivétel ekkor maga a hiba szövege, vagyis egy const char" típusú 
Ag-val terminált sztring. A hívási láncban a legközelebbi (és egyetlen) í77 
catch blokkot a main függvényben találjuk, ennek első catch ágának paramé 
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10.1. A kivételek használatának alapjai 





tere const char?" típusú. Ez megegyezik a dobott kivétel típusával, így a kivé- 
telt a catch ág el is kapja, a kivételkezelő kód pedig kiírja a dobott kivétel 
szövegét a hibakimenetre: t 





Ezt követően a futás a main függvényben a try-catch blokk után folytatódik 
(cout cc "This will be printed in all cases."; sor). 

A jelenlegi megoldásunkkal kapcsolatban megjegyezzük, hogy egy komoly 
hiányossággal bír: ha a Save függvényben a ValidateAndPrepare vagy DoSave 
függvény kivételt dob, akkor a fájlunk lezáratlan marad. A probléma részle- 
tezésére és a megoldás ismertetésére a 10.1.4 Az elkapott kivétel újradobása 
fejezetben térünk vissza. 


10.1.3. Egymásba ágyazott try-catch blokkok 


Bár az előző példában egyetlen try-catch blokk található, a try-catch blokkok 
egymásba is ágyazhatók. Így lehetőségünk van arra, hogy bizonyos kivételeket 
a dobott kivételhez közel, alacsonyabb szinten kezeljünk. Induljunk ki az előző 
példából, de most tegyük fel, hogy a Save függvényben a ValidateAndPrepare és 
a DoSave függvény által dobott hibakód (int) típusú kivételeket helyben szeret- 
nénk kezelni. A megoldáshoz csak a Save függvényt kell módosítani: 
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A ValidateAndPrepare és a DoSave által dobott int típusú kivételeket a Saye 

levő try-catch blokk elkapja, a futás ilyenkor ezen try.cgtej 
blokk után folytatódik, vagyis a Save függvény visszatér. Fontos, hogy ha a 
ValidateAndPrepare vagy a DoSave függvény nem int típusú kivételt dol 
azokat a Save függvényben levő try-catch blokk nem kapná el, kezelésük ma. 
gasabb szinten történne (a const char" típusúaké a main függvényben, az 
egyéb kivételek pedig kezeletlennek számítanának). 


10.1.4. Az elkapott kivétel újradobása 


Az elkapott kivétel a throw kulcsszó paraméter nélküli alkalmazásával újra. 
dobható. Nézzünk erre egy példát: 


Ismét a fejezet elején bemutatott példa Save függvényét alakítottuk át. Meg- 
oldásunk most már garantálja, hogy fájlunk akkor is lezáródjon, ha a Vali- 
gezt ndPrepare vagy a DoSave függvény kivételt dob. A ValidateAndPrepare 
SERA függvényeket azért kellett a Save-ben try-catch blokkba tenni, 

e nélkül nem is lenne lehetőség a file változó által reprezentált fájl lezá- 


rására, amikor a Vali vagy a DoSave kivételt dob. Ne feled: 
busa a Save-ből való kilépéskor a file lokális változó megszűnik! Az egyetlen 
eve ess megoldást a fenti példa mutatja: még a Save függvényben elkapjuk 
éhezés váli és a DoSave által dobott összes kivételt a catch(...) ki. 
ensső EÜ FRET a file változó által reprezentált fájlt, majd a kivételt 
Fly jel KENE KögejE ÉN újradobása azért kritikus lépés 
sőbbiekben még? ee tektált hibát. Erről a technikáról a 








10.1. A kivételek használatának alapjai 


10.1.5. A verem visszacsévélése 


Egy kivétel dobásakor annak elkapásáig a fü; ívási 

K ggvények hívási láncában felf. 
kget az egyes függvények lokális változói felszabadulnak. Ezt a ESZES 
tot a hívási verem visszacsévélésének (stack rewind) ü ü 
meg az alábbi kódrészletet: ÖÉSRSZER EV ÁSRA MKONAS 





A lépések a példában a következők: 


1. Az/f2 kivételt dob. 

2. Az /2-ben definiált i lokális változó felszabadul. 

3. Az /1-ben lefoglalt Fifo fifo objektum felszabadul, meghívódik a dest- 
ruktora. 

4. Lefut a main függvényben levő catcA blokk. 


Bár elsőre nem gondolnánk, a kivétel dobása és elkapása között kód futhat le, 
ugyanis meghívódnak a verem visszacsévélése során felszabadított objektu- 
mok destruktorai. Lényeges szabály, hogy a kivétel dobása és elkapása között 
ne dobjuk újabb kivételt, mert ennek kezelése már nem lehetséges, meghívó- 
dik a terminate, és az alkalmazás futása befejeződik. A gondolatmenetünk 
következményét útmutató formájában fogalmazzuk meg: 
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SEA ESTE át E Es ELÉG ÉS TE the slteeáezény észen intette nista mmm teminásizzámó 
Útmutató: Destruktorból soha ne dobjuk kivételt, flletve ha olyan kódot hívunk, amely kívé- 
telt dobhat, akkor a kivételeket a destruktorban alkalmazott try-catch blokkal kezeljük! 


Érdekességképpen megemlítjük, hogy a destruktorban az uncaught. exception 
függvény használatával lehetőség van annak megállapítására, hogy a destruk- 
tor dobott kivétel miatt került meghívásra, vagy valamilyen más okból. A függ- 
vény az első esetben true-val, a második esetben false-szal tér vissza. 


10.2. Kivételkezelés a gyakorlatban 


Az eddig bemutatott példákban a dobott kivételek egyszerű beépített típusúak 
voltak. Ennek egy komoly korlátja azonnal látszik: ha egy adott helyen a ki- 
vétel típusától függetlenül minden kivételt el akarunk kapni, akkor minden 
beépített típusra egy külön catch ágat kell bevezetni. Ez a megoldás a gyakor- 
latban használhatatlan. Gondolhatnánk a catch(...) alkalmazására, amely 
minden kivételt elkap, ám ez esetben a catch ágban nem tudunk hozzáférni a 
dobott kivételhez. További komoly problémával is szembesülünk beépített tí- 
pusok használatakor: ez a megoldás nem teszi lehetővé, hogy csak egy adott 
jellegű kivételt (például érvénytelen függvényparamétert, fájlkezelés hibát) 
kapjunk el. Ezekre a megoldást a kivétel osztályok alkalmazása jelenti. Mie- 
lőtt a gyakorlatban is jól alkalmazható megoldást bemutatnánk, meg kell is- 
merkednünk azzal, miben is nyilvánul meg a kivételek típusossága. 


10.2.1. A kivételek típusossága 


A Cs kivételek típusosak. A dobott kivételek lehetnék egyszerű beépített tí- 
pusúak vagy adott osztálybeli objektumok. Egy catch ág akkor kapja el a do- 
bott kivételt, ha a catch paraméterének típusa — a kivételillesztés tekinteté- 
ben - kompatibilis a dobott kivétel típusával, pontosabban: 


s A catch paraméterének típusa pontosan egyezik a dobott kivétel típu- 
sával. Például a throw 10;-et elkapja a catch(int e), illetve a throw null- 
pointer. exception();-t elkapja a catch(nullpointer exception e). Ez utóbbi 
esetben feltettük, hogy a nullpointer exception egy osztály. A kivétel 
dobásakor másolat készül a dobott objektumról, és ez íródik be a catch 
paraméterébe. 


s A catch paramétere referencia a dobott kivétel típusára. Például a throw 
nullpointer. exception();-t elkapja a catch(nullpointer. exceptiondt e). 
,  Acatch paramétere a dobott kivétel ősosztálya. Például a throw null- 


pointer. exception();-t elkapja a catch(exception e), ha az exception a null- 
pointer. exception ősosztálya. 
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e  Acatch paramétere referencia a dobott kivétel ősosztályára. Például a 
throw nullpointer. exception();-t elkapja a catch(exceptiong; e), ha az 
exception a nullpointer exception ősosztálya. 


s — A pointer típusú dobott kivételek esetében akkor, ha a catch paramé- 
terben szereplő pointerre van a dobott pointer típusról konverzió. Pél- 
dául throw new nullpointer. exception();-t elkapja a catch(nullpointer 
exception" e), valamint a catch(exception" e) is, feltéve, hogy az exception 
a nullpointer. exception ősosztálya. Ha a dobott kivétel a new operá- 
torral dinamikusan lett létrehozva, akkor delete operátorral gondos- 
kodni kell a törléséről. Egyébként viszont tilos a delete operátor hasz- 
nálata. A pointer kivételek kezelésének ezen kettőssége miatt nem 
célszerű pointer kivételeket alkalmazni. A catch ágban ugyanis a ren- 
delkezésre álló nyelvi eszközökkel nem tudjuk ellenőrizni, hogy a pa- 
raméterben megkapott pointer dinamikusan vagy nem dinamikusan 
létrehozott objektumra mutat-e.50 


e — Valamennyi előző pontra igaz, hogy nem const dobott kivétel const- 
ként, illetve const dobott kivétel nem const-ként is elkapható.§! Egy 
példa: a throw nullpointer. exception();-t elkapja a catch(const null- 
pointer exceptiondz e). Pointerek esetében azonban vigyázzunk: egy 
nullpointer. exception?" const p pointer elkapható ugyan const és nem 
const pointerként is (catch (nullpointer exception? const p) és catch 
(nullpointer. exception" p)), de a mutatott objektum típusa szempont- 
jából már a normál konverziós szabályok érvényesek: a const null- 
pointer. exception" p-t csak a catch(const nullpointer exception" p) kap- 
ja el, a catch(nullpointer exception" p) már nem, vagyis const2nem 
const konverzió nem kerül alkalmazásra. Megjegyezzük, hogy a a 
sztring literál kivételek ebből a szempontból char" típusúnak tekin- 
tendők, vagyis a throw "Could not open file xxx." kivételt elkapja a 
catch (const char" e) és a catch (char" e) is. 


Ezt a viselkedést az indokolja, hogy kivétel dobásakor mindig másolat 
készül a dobott objektumról, illetve pointer esetén a dobott pointerről. 


e — Accatch(..) minden kivételt elkap, a dobott kivételobjektumhoz azon- 
ban nem férhetünk hozzá. 


Még ha referenciával kapjuk is el a kivételt, akkor is másolat készül róla. 
Ennek két következménye van. Egyrészt, ha a kivétel objektum, akkor meg- 
hívódik a másolókonstruktora. A másik, hogy nem okoz problémát, ha a do- 
bott kivétel lokális változó, illetve objektum: 





60 Trükkös egyedi megoldások kidolgozhatók ugyan, de ezek csak növelik a kód bonyolultságát. 
61 Ez utóbbi az általános konverziós szabályoknál nem érvényes, a kivételkezelés speciali- 
tásának tekinthető. 
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10. fejezet: Kivételkezelés 
2. Tejezet vetetett 


mm 
—rn 


A lokális e objektum megszűnik ugyan a kivétel dobásakor, de mivel másolat 
készül róla, és a catch ágban erre kapunk referenciát, a kivételobjektumhoz 
való hozzáférés (e.what()) a catch ágban ez esetben is teljesen legális. Lokális 
változóra mutató pointert viszont ne dobjunk, mert ekkor csak a pointerről 
készül másolat, így a catch ágban a pointerünk érvénytelen területre mutat! 

Megjegyezzük, hogy a catch esetében nem kötelező nevet adni a paramé- 
ternek, amennyiben nem kívánjuk felhasználni a kivételobjektumot: 





10.2.2. Kivételhierarchiák 


TANSKEOL SE egyik sarokköve, hogy - mint azt az előző fejezetben 
uk - ősosztálybeli típuson keresztül leszármazott osztálybeli dobott 


kivételt i ; gé; pagi obot 
teák TE el lehet kapni. Erre építve kivételosztály-hierarchiát szokás ki- 


EE) Útmutató: Soha ne dobjunk egyszerű tipusú kivételt! 


moj TEESÁDKZÁZ Cr Könyvtár is definiál egy kivételhierarchiát. Ebben 
tel. -2y 0se az exception osztály. A hierarchiában szereplő kivé- 
osztályok az alábbi ábrán láthatók: 
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28. ábra. A Szabványos C4-t Könyvtár kivételhierarchiája 


Következzen egy-egy gondolat az egyes kivételosztályokról: 


s — exception: minden kivétel ősosztálya. 


e logic error: olyan logikai hibák ősosztálya, melyek a program helyes 
megírásával elvileg elkerülhetők lennének. Önmagában is használa- 
tos, de vannak specializált alosztályai is, melyek a következők: 


s — domain. error: tartományhiba (matematikai értelemben): a meg- 
adott érték nincs a kívánt értéktartományban. 


s invalid argument: a függvény adott paramétere érvénytelen 
(például NULL, és ezt nem tekintjük érvényesnek). 


e length error: olyan műveletet végzünk, amely az adott környe- 
zetben túlmutat a maximálisan megengedett méretkorlátokon (pél- 
dául túl sok karakter hozzáfűzése sztring objektumhoz). 


, out of range: annak jelzésére használható, hogy a függvény 
adott paramétere nincs a megengedhető tartományban. Például 
érvénytelen a megadott tömbindex. 

e bad alloc: a new operátor általi helyfoglalás nem sikerült (kivéve, ha 
a new ,nothrow" verzióját használjuk az alábbi példának megfelelően: 
int" p - new(nothrow) int;) 

s bad cast: a dynamic. cast operátor dobja, ha futás közben nem sike- 
rült a konverzió. 

e bad typeid: a typeid operátor dobja, ha a paramétere nulla vagy 
NULL pointer. 
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"  runtime error: csak a futás közben detektálható hibák jelzésére al. 
kalmazható. Önmagában is használatos, de vannak specializált alosz. 
tályai is, melyek a következők: 


s" range error: egy belső számítás során érvénytelen tartományok 
jelzésére használható. 


e  overflow error: aritmetikai túlcsordulás jelzésére használható. 
e  underflow error: aritmetikai alulcsordulás jelzésére használható. 


s bad exception: akkor dobódik, ha függvény olyan kivételt dobott, 
amely ellentmond a függvény kivételspecifikációjának (a függvények 
kivételspecifikációjáról a 10.2.5. Függvények kivételspecifikációja feje- 
zetben lesz szó). 


. — iosbase:failure: a Szabványos C-t-t Könyvtár JO stream osztályai ál- 
tal használt kivétel, amelyet hiba vagy fájlvége esetén dobnak. 


Valamennyi kivétel az std névtérben definiált. A gyakrabban használtakhoz 
az Sexception:, a többihez az cstdexcept? fejlécfájlt kell include-olni. Fontos 
gondolat, hogy ez a kivételhierarchia a Szabványos C--4 Könyvtár és nem a 
C44 nyelvi szabvány része! Sajnálatos módon — történelmi okokból — magá- 
ban a Cs nyelvben nincs olyan exception ősosztály, amelyből kötelezően va- 
lamennyi kivételosztálynak le kellene származnia (5 így amely ősosztályon 
keresztül valamennyi kivétel egységesen elkapható lenne).52 A régebbi osz- 
tálykönyvtárak sok esetben a Szabványos C--4- Könyvtárétól teljesen független 
kivételhierarchiát definiálnak, ilyen például a Microsoft Foundation Classes. 
Sőt, semmi sem akadályoz meg minket abban, hogy teljesen egyedi, saját ki- 
vételhierarchiát alakítsunk ki. A fejezetben azonban maradunk a Szabványos 
C4-4 Könyvtár kivételeinek használatánál, ugyanis így jól bemutatható a ki- 
vételosztályok helyes alkalmazása, illetve ezek felhasználásával saját kivé- 
telosztályok is bevezethetők. 
Az exception osztály definíciója a következő: 








sz A Javában és a .NET nyelvekben minden dobható kivételnek van egy közös ősosztálya. 





10.2. Kivételkezelés a gyakorlatban 
—— — SS ee ÍV L Nyetelkezelés a gyakorlatban. 


A kivételekhez tulajdonképpen a kivétel szövege, egy "NO-sal terminált C string 
tartozik, amely a kivétel leírását tartalmazza. Ezt az exception osztály konst- 
ruktorában lehet megadni. Az alapértelmezett konstruktor a kivétel szövegét 
üresen hagyja. A kivétel leírása a what metódussal kérdezhető le. Ez a what 
virtuális tagfüggvény a leszármazott osztályok esetében felüldefiniálható, de 
minden esetben const char" típussal kell visszatérnie, amelynek természet- 
szerűen a kivétel leírását kell adnia. A tagfüggvény-deklaráció végén található 
throw() a tagfüggvény kivételspecifikációja, jelentéséről a 10.2.5. Függvények 


kivételspecifikációja fejezetben lesz szó. 
A kivételosztályok használatára mutat példát az alábbi kódrészlet: 


finclude ciostream: 
tinclude cexceptionz 


using namespace std; 


void print(const char" str) 
t 
if(str -— NULL) ér 
throw invalid argument("The str parameter can not be NULL."); 


cout cc str cc endi; 
; 


void testO 
( 


// Bizony, ez kivétel Tesz ... 
print(NULL) ; 


3 s 


int mainO 
£ 
try 
í 
testO; 


catch(const invalid argumentg e) 


3 cerr ec "Invalid argument: " cc e.whatO cc endi; 


J et da Ét ÉR 
catch(const exception§ e) ; j 
; cerr a "Application error: " cc e.whatO 


93 Ni ésVő 


J 
catch(...) 
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A kódrészlet működése a következő. A main függvényben egy try-catch blokkból 
történik a test függvény hívása, amely pedig többek között meghívja a print 
függvényt. A print függvény kiírja az str paraméterben megkapott sztringet a 
szabványos kimenetre. Előtte azonban az str paraméterre vonatkozóan ellenőr- 
zést végez: ha az értéke NULL, invalid. argument kivételt dob. 

A main függvényben a kivételkezelő jellegzetes felépítése figyelhető meg: 


s — Ha vannak olyan kivételtípusok, amelyek speciális kezelést igényel- 
nek, akkor ezek kezelő catch ágait vesszük előre. A példánkban egy 
ilyen volt: az invalid argument típusú kivételeket külön kívántuk ke- 
zelni (bár a példa egyszerűsége miatt ez erőltetettnek tűnik). 


s — Ezt követi a catch(const exceptiont e), aminek szerepe valamennyi 
speciális kezelést nem igénylő kivétel elkapása és egységes módon tör- 
ténő kezelése. Ez az ág az összes exception és exception leszármazott 
osztálybeli kivételobjektumot elkapja, és az e.what() virtuális függ- 
vény hívásával a kivételobjektumból kinyeri annak kivételspecifikus 
leírását, amit kiír a hibakimenetre. Itt válik nyilvánvalóvá, miért 
alakították ki a kivételkezelés mechanizmusát úgy, hogy ősosztálybeli 
típuson keresztül valamennyi leszármazott osztálybeli kivételt meg 
lehessen fogni. Ez teszi ugyanis lehetővé, hogy a kivételeket 
egyetlen catch ággal, egységes módon lehessen kezelni. 


s Egy lényeges kikötés: a speciálisabb (leszármazott osztálybeli) kivéte- 
lek catch ágainak az általánosabbak catch ágai előtt kell szerepelniük. 


s — AXKkivételeket referenciaként, sőt konstans referenciaként célszerű el- 
kapni. Ez esetben a dobott kivételről csak egyszer készül másolat, így 
egyszer hívódik a kivételosztály másolókonstruktora. Ennél komo- 
lyabb érv is szól azonban mellette. Ha referenciaként kapjuk el a 
dobott kivételt, akkor a referencia a dobott kivétel típusának megfelelő 
kivételre hivatkozik akkor is, ha ősosztálybeli típusként kaptuk el. 
Például a throw invalid. argument és catch (exceptiong e) esetén az e 
referencia mögött a dobott invalid argument objektum van. Ha 
ugyanebben a helyzetben nem referenciaként kapjuk el a dobott kivé- 
telt ((hrow invalid. argument és catch (exception e)), akkor fellép a vá- 
gás, slicing-on-the-fly jelensége (lásd 8.2.2. Konverzió az öröklési hierar- 
chia mentén fejezet). Az elkapott kivételobjektum ősosztálybeli típusú 
lesz, bármi volt az eredeti kivétel. Ennek következtében elveszik a 
kivételspecifikus információ, hiába volt a leszármazott kivételosztály- 
ban felüldefiniálva a what virtuális metódus! 


e A catch(...) ág szerepe, hogy valamennyi nem , tisztességes" kivételt 
elkapjon. Itt fogalmunk sincs a tényleges hibáról, hiszen nem kapjuk 
meg a kivétel paramétert. Azért írtuk bele a kódba, hogy mi lépjünk ki 
az alkalmazásból, ne az operációs rendszer közölje a hibát a felhasz- 





10.2. Kivételkezelés a gyakorlatban 
s LES ee EYORO ÉDEN 


nálóval. Az egyszerű típusokat általában itt kapjuk el, mert nem írunk 
mindegyikre catch blokkot (pl. catch(const char" e), catch (int e) stb.). 
Ha egyedi kivételtípust kívánunk használni, származtassunk mindig 
az exception osztályból vagy annak egy leszármazottjából! 


10.2.3. Saját kivételosztályok 


Természetesen lehetőség van saját kivételosztályok bevezetésére is, ha az adott 
esetben a környezet (például Szabványos CH-- Könyvtár) által biztosított egyet- 
len kivételosztály sem felel meg céljainknak. Az általunk bevezetett kivételosz- 
tályok a meglevőkhöz képest több információt hordozhatnak (így a hiba jobb le- 
írását adhatják), valamint lehetőséget biztosítanak a saját kivételeinkre vonat- 
kozó egyedi szűrésre és hibakezelésre: a catch (const sajat kivetelosztalykt e) 
például csak a sajat kivetelosztaly típusú kivételeket kapja el, így ebbe a catch 
ágba speciális kezelőkód írható. Az alábbi példában egy nullpointer exception 
nevű kivételosztályt vezetünk be, és ennek használatát mutatjuk be: 


$include ciostreams 
$include cexceptions 


using namespace std; 
const int MAX EXCEPTION MESSAGE LEN - 512; 


class nullpointer. exception: public exception 

ú // Itt hozzáadunk az adott kivételre jellemző 
// további adatot az alaposztályhoz. 
char variableName[ MAX EXCEPTION MESSAGE. LEN] ; 
// A kivétel teljes szövege 
char msgrext[MAX EXCEPTION MESSAGE. LEN]; 


public: § 
nullpointer exception(const char " variable) 


í 
strncpy(variableName, variable, MAX EXCEPTION. MESSAGE. LEN) ; 


variableName [MAX EXCEPTION MESSAGE. LEN-1] — "10"; 


snprintf(msgrText, MAX EXCEPTION. MESSAGE, LEN, f 
"The variable Xs can not be null.", Variable); 
msgrText[(( MAX. EXCEPTION, MESSAGE, LEN-1]) - "0 b 
) AGA 








const char: what() const 


t ; ; 
return — msgText; 
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A példában a kivételosztályunkat az std:rexception osztályból származtattuk le. 


SÉETENRERPZE PEGTESZZE BET ZETT JEE ZTE tezeeeeeee ME I 
Ga ; Útmutató: Az általunk bevezetett kivételosztályokat a környezetünk által biztosított kivé- 


telosztályokból származtassuk le! Ha a Szabványos Cs. Könyvtárat használjuk, akkor ősosztály- 


ként az exception vagy annak az általunk bevezetni kívánt osztál ésé 3; 
lebb álló leszármazott osztályát használjuk. yhoz jelentésében legköze- 


Tegyük fel, hogy a nullpointer. exception osztályt bármilyen belső számításnál 
fel kívánjuk használni annak jelzésére, ha nem várt módon NULL egy változó 
értéke. Ha csak Pointer függvényargumentumok ellenőrzése során szeretnénk 
ERT ÉL az invalid argument osztályt lenne célszerűbb ősosztályként fel- 

Azáltal, hogy nullpointer exception osztályunkat az exception ősből 
származtattuk le, alapvetően azt érjük el, hogy ha kivételünkre vonat- 
kozóan nem kívánunk speciális kezelést biztosítani, akkor a main 
raj slztetss levő catch (const exception e) kivételkezelő ág ,au- 
tomat megfogja, és általános módon kezeli! 








lemző tagváltozó tartozik: a va 








exception ősosztályra, ez azonban esetű ( a kivétel 


teljes szövegének tárolására az msgText tagváltozót vezetjük be. 

A konstruktornak csak a problémát okozó változó nevét kell megadni. 
A konstruktorban található strncpy és snprintf függvény hasonlóan működik a 
jól ismert strepy és sprintf függvényhez, ugyanakkor használatukkal elkerül- 
hető a puffertúlcsordulási (buffer overrun) probléma: mivel a maximális ka- 
rakterszám is megadható paraméterként, biztosítható, hogy az allokált puffer 
méreténél több karakter ne kerüljön kiírásra. Az snprintf sajnos nem része az 
ANSI C szabványnak, így nem minden fordítói környezet támogatja. 

A nullpointer. exception osztályunkban az ős what virtuális függvénye fe- 
lüldefiniálásra került, hogy az általunk bevezetett és a konstruktorban kitöl- 
tött msgText hibaszöveggel térjen vissza. A get VariableName tagfüggvénnyel 
a problémát okozó, NULL értékű változó neve kérhető le. 

Példánkban a nullpointer exception-t központi módon, a main függvény- 
ben a többi kivétellel egységesen kezeljük. Természetesen a hívási lánc bár- 
mely szintjén lehetőség van a kivételünk egyedi kezelésére. Ennek szemlélte- 
tésére test függvényünket módosítsuk a következőképpen: 








$3 Az exception alaposztály által TELÁNEZNENT tagváltozó SEU ősben private és 
csak az exception konstruktorában meg. a szt 
inicializálási listájában pedig nem tudjuk az ős számára előállítani a formázott Érszájsén ; 
44 Előfordulhat, hogy a függvénnyel . snprintf néven találkozunk, Használhatj d szabvá; 
nyos sprintf(msgText, "The parameter "08 can nöt be null." Baramist, de ez neg Ayújt meg- 
oldást a puffertúlcsordulási problémára. 
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Sea 


A kivétel egyedi kezelésének a példánkban annak egyszerűségéből adódóan 
nem volt különösebb értelme. Gyakorlatiasabb példa lehet a következő: háló. 
zati kommunikáció esetén bevezethetünk egy network error nevű kivételosz. 
tályt, amelyet a hálózati hibák detektálásakor dobunk, ennek egyedi kezelé. 
sében pedig megpróbálhatjuk helyreállítani a hálózati kapcsolatot. 


10.2.4. Kezeletlen kivételek 


Ha egy dobott kivételt a legmagasabb szinten, a main függvényben sem ka. 
punk el, kezeletlennek számít. A kezeletlen kivételek esetében az std névtér- 
ben definiált terminate függvény hívódik meg, amely alapértelmezésben az 
abort függvényt hívja. Amennyiben ez a viselkedés számunkra nem felel meg, 
a set terminate függvénnyel saját, a terminate által hívandó kezelőfüggvény 
is megadható: 








13 Kés E : 
ed by terminate: 


A set terminate függvénynek void paraméterű és void visszatérésű függvények 
címe adható meg. Lényeges megkötés, hogy a saját kezelőfüggvény nem térhet 
vissza a hívóhoz, a példában ezt biztosítja az exit(-1) hívás. Ha függvényünk 
mégis visszatérne, automatikusan meghívódna az abort függvény. A set termi- 
nate az aktuálisan érvényben levő kezelőfüggvény címével tér vissza, így az el- 
menthető, és a későbbiekben visszaállítható. A saját kezelőfüggvény megadá- 
sának célja a kilépés előtti takarítás, valamint az eset naplózása lehet. 


10.2.5. Függvények kivételspecifikációja 


A Cst nyelvben lehetőség van a globális függvényekre és metódusokra v0- 
natkozóan a deklaráció során specifikálni, hogy milyen kivételt dobhatnak. 
Ezt a függvény kivételspecifikációjának (exception specification) nevezzük. 
Néhány egyszerű példa: 
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Az egyes függvények a következőt , állítják magukról": 


se — Azficsak bad. alloc és ebből leszármaztatott kivételt dobhat (mást nem). 


e — Az f2 csak bad alloc és invalid argument, illetve ezekből leszármaz- 
tatott kivételt dobhat. 


e — Azf3nem dob kivételt. 
s — Azf4és az f5 ekvivalens: mindkét függvény bármilyen kivételt dobhat. 


Sajnos annak ellenőrzése, hogy a függvény implementációja megfelel-e a speci- 
fikációjának (például, ha azt állítja magáról, hogy nem dob semmit, akkor az 
tényleg úgy is legyen), nem történik meg fordításkor. Ellenben ha futás közben 
a függvény olyan kivételt dob, amely ellentmond a specifikációjának, akkor a 
kivétel nem dobódik tovább, hanem meghívódik az std névtérben definiált 
unexpected függvény. Az unexpected függvény alapértelmezésben meghívja az 
std névtérben levő terminate függvényt (amely pedig alapértelmezésben abortot 
hív). Ha ennél kevésbé drasztikusan kívánjuk kezelni a helyzetet, két lehetősé- 
günk van. Egyrészt, ha a függvény kivételspecifikációjában a bad exception ki- 
vételt is szerepeltetjük (pl. void f1() throw(bad, alloc, bad. exception)), akkor az 
unexpected függvény a terminate hívása helyett bad exceptiont dob. Másrészt 
lehetőség van saját kezelőfüggvény megadására a set unexpected függvénnyel. 

A kivételspecifikációról érdemes tudni, hogy alkalmazása nem terjedt el a 
gyakorlatban, napjaink legkorszerűbb C--t fordítói is csak korlátozottan tá- 
mogatják. 


10.3. Kivételkezelési technikák 


A kivételek alkalmazása a hagyományos hibakezelési technikákkal szemben 
megkérdőjelezhetetlenül számos előnnyel jár."§ A kivételek használata ugyan- 
akkor — különösen az erőforrások (fájl, dinamikusan foglalt memória stb.) me- 
nedzselésének tekintetében — különös körültekintést igényel. A komolyabb pro- 





66 Az is ezt bizonyítja, hogy valamennyi korszerű, magas szintű programozási nyelv támo- 
gatja a kivételek használatát. 
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jektek esetében már a fejlesztés kezdetén célszerű megfelelő kivételkezelési 
stratégiát kidolgozni. Ez természetesen nagyban függ az aktuális környezet- 
től. Jellemző stratégia a kivételek fájlba naplózása, majd ezt követően a kivé- 
tel súlyosságától függően az alkalmazásból való kilépés, vagy kevésbé komoly 
probléma esetén (például egy fájl megnyitása nem sikerült) a felhasználó tá- 
jékoztatása után az alkalmazás tovább futtatása. A legtöbbször az okozza a 
gondot, hogy ez utóbbi esetre vonatkozóan nem fordítunk kellő figyelmet arra, 
hogy az alkalmazás kivételek fellépésekor is konzisztens állapotban marad- 
jon, valamint ne következzen be az erőforrások elszivárgása. Ez tipikusan el- 
szivárgó memóriát, magunk mögött hagyott lezáratlan fájlokat, hálózati és 
adatbázis kapcsolatokat és egyéb platformfüggő leírókat"" jelent. Különösen 
azon alkalmazások esetében jelent ez problémát, melyeknek hosszú ideig kell 
nagy megbízhatósággal működniük. A fejezetben néhány olyan kivételkezelési 
technikát mutatunk be, melyek alkalmazásával a gyakorlatban elkerülhető az 
ilyen jellegű problémák többsége. Ugyanakkor meg kell említeni, hogy a té- 
makörnek önálló irodalma van, mi az egyszerűbb esetekre koncentrálunk. 


10.3.1. Erőforrás-kezelés 
Tekintsük meg az alábbi kódrészletet: 





A példában a MessageHandler egy bemeneti folyamból (istream) üzeneteket 
kiolvasó és azokat feldolgozó osztály. A ProcessMessages tagfüggvénye mind- 
addig Message (üzenet) objektumokat olvas a bemeneti folyamból a readNext- 





63 Egy példa: Win32 környezetben az operációs rendszer bek 3", mint például ablako- 
keresztül érhetjük el, melyeket használat után kötelezően le kell zárni. 
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Message függvény meghívásával, amíg az NULL-lal nem tér vi ü 
fel, hogy a readNextMessage a következőképpen működik: a Há szzától 
létrehoz egy Message vagy abból leszármazott objektumot, a hozzá tartozó 
adatokat kiolvassa a folyamból, és visszatér a Message objektumra mutató po- 
interrel. A ProcessMessages a readNextMessage hívását követően olyan függ- 
vényeket hív, melyek feldolgozzák a beolvasott üzenetet, ezt követően pedig a 
delete operátorral felszabadítja a Message objektumot. Probléma akkor adó- 
dik, ha az üzenet feldolgozását végző függvények (pl. a pMessage-2Process()) 
kivételt dobnak. Ez esetben ugyanis a delete hívás és így az utoljára beolva- 
sott Message objektum felszabadítása elmarad, ennek , utólagos pótlására" 
nincs lehetőség, a Message objektum által elfoglalt memória elszivárog. A kö- 
vetendő stratégiát az alábbi kódrészlet szemlélteti: 





Amennyiben az üzenet feldolgozása során bármilyen kivétel keletkezik, a 
catch(...)-csel elkapjuk, felszabadítjuk a helyileg lefoglalt memóriát, majd új- 
radobjuk a kivételt.§7 Ez utóbbi lépés alapvető fontosságú, hiszen a kivétel 
,lenyelése? esetén a hiba rejtve maradna, kiszámíthatatlan következmények- 
kel. A tapasztalatok a következőképpen általánosíthatók: 





7 A Java és a .NET nyelvekben létező try-finally konstrukcióval hasonló esetben elegánsabb 
megoldás is készíthető, a try-finally konstrukciót a C-t nyelv azonban nem támogatja. 
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TETTETETT BEST. TETT TESSENEK EJTI ESZETEKBE ESET Tee mee 
Útmutató: kivételek esetén is gondoskodjunk a lokálisan lefoglalt erőforrások, úgymint di. 
namikus memória, fájl, hálózati és adatbázis kapcsolat, operációs rendszer leírók stb. felsza- 
badításáról. 





10.3.2. Bevezetés az auto ptr használatába 


A lokális erőforrások felszabadítására kihasználhatjuk azt a tényt, hogy egy 
adott blokkból (például függvényből) kilépve az adott blokk lokális változói, 
objektumai felszabadulnak. Az objektumokra vonatkozóan ez azt jelenti, hogy 
meghívódik a destruktoruk. A , trükk" a dologban az, hogy teljesen mindegy, 
milyen okból kifolyólag történik a blokkból való kilépés. A destruktor meghí. 
vása ekkor is garantált, ha egy kivétel következtében lépünk ki. Ezt kihasz- 
nálva a lokális erőforrások felszabadítását lokális objektumok destruktoraira 
bízhatjuk. Erre a koncepcióra épít a Szabványos C--t Könyvtár auto. ) ptT 0sz- 
tálya is. Ennek konstruktorában megadhatunk egy pointert, amelyre vonat- 
kozóan az auto ptr objektum a destruktorában delete-et hív. Az auto ptr osz- 
tálysablon"§ a cmemory? fejlécfájlban definiált. Egy az auto ptr használatát 
illusztráló , minimális" kódrészlet a következő: 





Az auto ptr objektumai tulajdonképpen egy, a konstruktorukban megadott 
pointert csomagolnak be átlátszó módon. Az auto ptr az std névtérben defi- 
niált osztálysablon. Sablonparaméterben a becsomagolni kívánt pointer típu- 
sa adandó meg (a példánkban IntFifo). A példánkban a pt egy auto. ptr objek- 
tum, amelynek konstruktorában egy dinamikusan lefoglalt, IntFifo objek- 
tumra mutató pointert adunk át. A pt objektum úgy használható, mintha 
maga a becsomagolt pointer lenne, erre mutat példát a pt-2Put(10); sor. Ez 
azáltal valósulhat meg, hogy az auto ptr osztálysablonban az operator-2 és 
operator?" megfelelően felül vannak definiálva. Az auto ptr tehát nagyon ké- 
nyelmesen használható. Az egyszerű pointerekhez képest azonban nyújt egy 
extra szolgáltatást: a destruktorában delete-et hív a becsomagolt pointerre. 
Azt mondjuk, hogy a pt auto. ptr objektum birtokolja a new által dinamikusan 
lefoglalt objektumot. Mire jó ez az egész? A megoldás tuljadonképpen 2 
ee en. ez Re 

5 Az osztálysablonokat a 11.2. fejezetben vezetjük be. 
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memóriaszivárgás megelőzését szolgálja elegáns módon. Ha a pt közönséges 
pointer lenne, akkor a new által lefoglalt memória elszivárogna, amennyiben a 
pt-2Put(10);, vagy a test függvényben levő további kódkivételt dob.§9 A fenti 
megoldásban azonban ez nem következik be, mert akármilyen okból kifolyó- 
lag lépünk is ki a test függvényből (legyen az egy dobott kivétel), a Pt lokális 
auto. ptr objektum felszabadul, meghívódik a destruktora, amely pedig felsza- 
badítja a dinamikusan lefoglalt memóriát! 

Az auto ptr nem végez referenciaszámlálást, mindössze a memóriabirtok- 
lási viszonyt fejezi ki. A lefoglalt memóriának mindig pontosan egy auto ptr 
objektum a tulajdonosa, amely az operator— és másolókonstruktor hívásakor 
automatikusan átadódik: 





A helyes működést az biztosítja, hogy a dinamikusan lefoglalt memóriát min- 
dig csak annak tulajdonos auto ptr objektuma szabadítja fel a destruktorá- 
ban. Az előző fejezet kiindulási problémájára megoldást adó auto ptr alapú 
megoldás a következő: 





s9. Ennek kivédésére láttunk az auto ptr használatát nem igénylő megoldást az előző feje- 
zetben. 
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i 10.3.3. A konstruktor és a destruktor működése b 


Fontos tudatában lenni, hogy a destruktor csak a teljesen megkonstruált 

objektumok esetén fut le. Ha egy osztály konstruktora, ősének konstruk.. 

i tora vagy egy beágyazott objektumának konstruktora kivételt dob, akkor az 

i objektuma nem lesz teljesen megkonstruált. Ezekben az esetekben a destruk- 
tor nem fut le. Ilyen helyzetet mutat be az alábbi kódrészlet: 
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Egy megjegyzés: amennyiben a new kivételt dob — mert nem sikerült a memó- 
riafoglalás —, a delete paramétere NULL lesz, ami a C-t nyelvben teljesen legá- 
lis. Ennél fontosabb gondolat azonban, hogy az elkapott kivételt újradobjuk. 
A kivétel , lenyelésénél" rosszabbat nem tehetnénk, a hiba rejtve maradna. 





Útmutató: Ne tartsunk attól, hogy a konstruktor kivételt dob. Ennek káros következménye 
nem lehet, mindössze a teljes megkonstruáltságra vonatkozó szabálynak legyünk tudatában. 


Rendben, jegyezhetnék meg a rutinosabb fejlesztők, de mi a helyzet öröklés 
esetén, amikor a hierarchiában bármelyik konstruktor kivételt dobhat. Ez 
esetben az objektumunk nem lesz ugyan teljesen megkonstruált, de a hierar- 
chiában azon ősosztályok destruktora meghívódik, amelyek konstruktora a 
kivétel dobása előtt teljesen lefutott. Nézzük meg az alábbi példát: 
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A kivétel dobása a B osztály konstruktorában történik. Mivel az A osztály 
konstruktora ekkorra már teljesen lefutott, az A osztály destruktora meghí- 
vódik. Ezzel ellentétben a kivétel dobásának pillanatáig a B osztály konstruk- 
tora csak részben futott le, a C osztályé pedig egyáltalán nem, ezek destruk- 
tora nem hívódik meg. Ennek megfelelően a fenti kód a következőt írja ki: 





ek jó 1 belegondolunk, korábban kidolgozott megoldásunk szerencsére öröklés 
esetén is jól működik. Vagyis, ha egy konstruktor kivételt dobhat, és dinamikt- 
san foglalunk le erőforrást, akkor még a konstruktorban kapjuk el a kivételt, 
szabadítsuk fel az erőforrást, majd a kivételt dobjuk újra a throzw utasítással. 
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TIZENEGYEDIK FEJEZET 
C-11 sablonok 


A 3.5.2. Dinamikus adattagok támogatása részben ismertetett IntFifo osztály 
kapcsán felmerülhetett bennünk a kérdés: ha nem int, hanem más típusú 
elemeket kívánunk tárolni, akkor a különböző FIFO verziók manuális elké- 
szítésén kívül van-e más lehetőségünk. A válasz szerencsére igen, a C$- sab- 
lonok alkalmazása — többek között — erre a problémára is megoldást nyújt. 

Ct- sablonok (template) alatt olyan osztálysablonokat (class template) 
és függvénysablonokat (function template) értünk, melyek esetében az 
adott osztály, illetve függvény definiálásakor bizonyos elemeket nem adunk 
meg, hanem paraméterként kezelünk. Ezen paraméterek megadása explicit 
vagy implicit módon az adott osztálysablon, illetve függvénysablon felhasz- 
nálásakor történik. Egy példa: a korábban ismertetett IntFifo osztályunk 
csak int típusú elemeket tudott tárolni. Az osztályt osztálysablonná alakítva 
az elem típusát paraméterként kezelhetjük, és a kívánt elemtípust az osz- 
tálysablon felhasználása során adhatjuk meg. 

Ne ijedjünk meg, ha a fenti definícióból egyelőre csak ködös képet tudunk 
kialakítani. A C-t sablonok programozására különösen igaz, hogy már fo- 
galmi szinten is példákon keresztül lehet megérteni, amelyeket a rövid beve- 
zető után bőségesen alkalmazni is fogunk. Egyelőre gondoljunk úgy a sablo- 
nokra, mint olyan osztályokra, illetve függvényekre, melyek nem teljesek, és 
a felhasználásukkor a paraméterek megadásával válnak teljes értékű osztá- 
lyokká vagy függvényekké. 

A C-4-- sablonok tulajdonképpen a generikus típusok Ct- nyelvbeli megfe- 
lelői.70 Jellemző alkalmazási területük olyan tárolóosztályok (például dinami- 
kusan nyújtózkodó tömb, láncolt lista stb.) létrehozása, amelyek tetszőleges 
típusú elem tárolására használhatók fel, mégpedig típusbiztos (type safe) mó- 
don. Erről bővebben később olvashatunk. A generikus típusok (vagyis a Ctt 
nyelvben a sablonok) ennél sokkal szélesebb körben alkalmazhatók hatéko- 
nyan, a keretrendszer fejlesztők kedvenc eszközei.7"! Való igaz, hogy a sablo- 
nok szintaktikája első ránézésre ijesztő lehet, de néhány alapszabály megis- 
merését követően a sablonok könnyen létrehozhatók, illetve felhasználhatók. 

Fontosnak tartjuk megjegyezni, hogy nem célunk a sablonok programozá- 
sának valamennyi részletét mélységében ismertetni, ez egy önálló kötetet is 


70 Genérikus típusok létrehozására az ismertebb nyelvek közül sokáig csak a Ctt nyelvben 
volt lehetőség, napjainkban vált csak támogatottá például a Ctt és a Java nyelvekben. 4 

n Ez az állítás csak akkor igaz, ha a forráskód védelme nem fontos szempont, a szávdnáó 
felhasználásához ugyanis, mint látni fogjuk, a sablonok forráskódját is rendelkezésre kel 
bocsátani. 














11. fejezet: Cst sablonok 


kitölthetne. Fontosnak tartjuk ellenben az alapok ismertetése után a sablg. 
nok programozásának néhány egzotikusnak tűnő aspektusát (például öröklés, 
sablonspecializálás stb.) is röviden bemutatni. Ezzel olyan szintű ismereteket 
kívánunk nyújtani, melyek alapján egyrészt az elterjedtebb, sablonokat is al. 
kalmazó C--4 osztálykönyvtárak (mint a Szabványos Ct-t Könyvtár) felhasz. 
nálásakor már nem lesznek , szintaktikai nehézségeink", másrészt célunk egy 
olyan sablonprogramozói eszköztár biztosítása, amelynek felhasználásával 
osztálysablonok és függvénysablónok írásakor képesek leszünk a problémák 
szélesebb körű megoldására. 


11.1. Függvénysablonok 


Legyen a feladat két függvény megírása: az első két egész szám (int), a máso- 
dik két komplex szám (Complex) közül a nagyobbal térjen vissza. A komplex 
számok reprezentálására a 6.3. Példa: egy komplex számokat megvalósító os2- 
tály fejezet Complex osztályát használjuk fel. A megoldás a következő: 







a feúr hs 7 1hsz rhs; 
y/ . inline conplex maxCconplex Ahs, complex rhs) 





A komplex számokra természetesen csak akkor működik a fenti megoldás, ha 
a ,2" operátort előzőleg megfelelően megírtuk (például a nagyobb abszolút ér- 
tékű komplex számmal térjen vissza). Szembeszökő a két függvény esetében, 
hogy a függvények törzse pontosan megegyezik. Ha újabb típusokra szeret: 
nénk használni max függvényünket, akkor azokra is külön meg kell írni. 
Ezen kódduplikálás elkerülésére eddigi ismereteink szerint egyetlen megol- 
dás kínálkozik, a makrók alkalmazása. A makrókkal kapcsolatos gondokat a 
korábbi fejezetekben már láttuk. A C-t nyelvben a probléma hatékony és biz: 
tonságos megoldására a függvénysablonokat használhatjuk. A max függ 
vényre vonatkozóan ez azt jelenti, hogy olyan függvénysablonná alakítjuk át, 
amelyben a típus, amelyen dolgozik, nincs rögzítve, paraméterként kezeljük, 
és ezt a paramétert a függvénysablon felhasználásakor adjuk meg. 
A max függvénysablon implementációja a következő: 
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——————— —— — — Má: Fizévényablötok 


A függvény átalakítását a következő lépésekben végeztük el. 


e — A függvénysablon fejlécét a template kulcsszóval kell kezdeni. A template 
kulcsszót követően € 5 között kell felsorolni a sablonparamétereket, 
vesszővel elválasztva. A példánkban egy sablonparaméter szerepel, 
ennek a T nevet adtuk. A sablonparamétereknek tetszőleges miévát 
adhatunk. Példánkban a T paraméter egy típust jelöl, ezt a tényt a 
class kulcsszóval jelezzük a fordító számára. A class helyett a type- 
name kulcsszó is használható, a kettő teljesen ekvivalens. A class 
kulcsszó némiképp megtévesztő, az adott paraméter nemcsak osztály, 
hanem tetszőleges típus lehet (például beépített típus, mint példánk- 
ban az int, vagy struktúra is). Sablonparaméter konstans is lehet, er- 
ről bővebben a későbbiekben olvashatunk. A template 6 után célsze- 
rű beszúrni egy sortörést, ez olvashatóbbá teszi a kódot, így a későb- 
biekben már ezt a formát fogjuk alkalmazni. 


e — Mindenhol, ahol eddig az int/Complex beégetett típust használtuk, a 
T paramétert szerepeltetjük. Ez esetünkben a függvény visszatérési 
értékének és paramétereinek típusát jelenti, de többek között lokáli- 
san definiált vagy dinamikusan lefoglalt változók létrehozására is 
használhatnánk. 


A példában a függvény, illetve a függvénysablon a függvénytörzs rövidsége 
miatt célszerűen inline, de természetesen nem inline függvénysablonok írásá- 
ra is van lehetőség. 8 

Eddig csak arról esett szó, hogyan lehet függvénysablont létrehozni. A kö- 
vetkezőkben azt nézzük meg, hogyan lehet a függvénysablonokat felhasználni. 
A legegyszerűbb mód a függvénysablon implicit példányosítása (implicit 
function template instantiation), amelyet az alábbi kódrészlet szemléltet: 





A kódrészlet első sora int, a második sora double típussal példányosítja? a 
függvénysablont. Ez azt jelenti, hogy a fordítás során az első esetben a T 
paraméter helyébe int, a második esetben double típus helyettesítődik. A be- 
helyettesítést követően a függvénysablonból közönséges függvény , születik", 
amit a fordító gépi kódra fordít. Példánkban ez két függvény kódjának lege- 
nerálását jelenti. Jelen esetben ezért beszélünk implicit példányosításról, 
mert a fordító a paraméterek típusából kikövetkezteti, milyen típust kell be- 
helyettesíteni a sablonparaméterek helyére, vagyis a paramétereket nem ad- 
tuk meg explicit módon. 





12. Ennek semmi köze az objektumok példányosításához (amikor egy adott osztályból egy ob- 
jektumpéldányt hozunk létre). 
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11. fejezet: Csr sablonok 

Implicit példányosítás esetén egy adott sablonparaméter csak egy típust 
jelölhet, A példára vonatkozóan ez azt jelenti, hogy a fordító kikényszeríti, 
hogy a max függvény mindkét paraméterének típusa pontosan megegyezzen. 
Ennek megfelelően például a 


GEZHGTBNEŰESNÁKSTTEDNK STT ETEK VST Ét 11717 771 STER ERBRENNTBÁNAONSBANI 


kód nem fordul le, mert az első függvényparaméter esetében a T int, a máso- 
dik esetében double típust jelentene. A fordító a függvénysablon implicit pél- 
dányosítása esetén nem engedélyezi az automatikus konverziót. Természete- 
sen ugyanígy fordítási hibát eredményezne, ha a függvényparaméterek nem 
konstansok, hanem változók lennének. Sőt, az unsigned és a signed típusok 
közötti konverzió sem megengedett. A probléma megoldása lehet a következő: 


FEGYASÜBTSKÁSZMAKCSTÓTSÍSJT TVEJETTBŰ MGSSZSS Ez) 





Itt mindkét paraméter típusa double. Változókkal szemléltetve: 





A másik megoldást a konverziós problémára az jelenti, ha a max függvénysablont 
explicit módon példányosítjuk (explicit function template instantiation): 


[sug VT €007 ÉGEK KKZZÁRROANNR 


Ebben az esetben a függvénysablon használatakor a függvénysablon neve után 
c 5 között, vesszővel elválasztva felsoroljuk a paraméterek behelyettesítési ér- 
tékét. A példában ez a 7 paraméterre a double megadását jelenti. A fordító ez 
esetben a 7 helyére double-t helyettesít, és az ennek megfelelő kódot generálja 
le. Az expliciten példányosított függvények esetében a paraméterekre működik 
az automatikus konverzió, vagyis a maxcdouble?(3, 3.5) nem okoz fordítási hi- 
bát: az első int paraméter (3) automatikusan double-ra konvertálódik. Ez logi- 
kus következménye annak, hogy az explicit módon példányosított függvény- 
sablonok ugyanúgy viselkednek, mint a közönséges függvények, ennek 
lően pontosan ugyanazok a konverziós szabályok érvényesek rájuk is. 
Felmerülhet bennünk a kérdés, hogy a max függvénysablonunk ténylege- 
sen bármilyen típussal használható-e, vagyis van-e valamiféle megkötés a T 
sablonparaméterre vonatkozóan. Vessünk még egy alaposabb pillantást 2 
függvénysablon implementációjára, ami magában rejti a választ: 











1 


Ezen implementáció esetén két megkötés él a T sablonparaméterre vonatkozóan: 


e. A függvény törzsében használjuk rá a 5 operátort, így a T típusra ér- 
telmezettnek kell lennie, és az általunk elvárt módon kell megvalósí- 
tania az összehasonlítást. Így ha T egy saját osztály vagy struktúra, 
akkor gondoskodjunk a 5 operátor megfelelő megírásáról. ű 


e A függvény az lhs és rhs paramétereket érték szerint (nem referencia- 
ként) veszi át, valamint nem referencia T típussal tér vissza, így a függ- 
vény hívásakor meghívódik a 7 másolókonstruktora. Ha T saját típus, 
gondoskodjunk megfelelő másolókonstruktor megírásáról, amennyiben B 
beépített másolókonstruktor nem biztosít megfelelő működést (ennek 
szükségszerűségét a 3.5.3. A másolókonstruktor fejezet tárgyalja). 


Megjegyezzük, hogy nagyobb objektumok esetén a fenti max függvénysablon- 
implementációnál hatékonyabb működést eredményez a referenciaként törté- 
nő paraméterátadás: 


template cclass T: Taj era 
inline const T8 max(const T8 1hs, const T8 rhs) 12 DAYS, 


return 1hs 5 rhs ? 1hs: rhs; t érhi ] 
ja 1. - öt 


11.1.1. Függvénysablon-specializáció 


Tekintsük az előzőekben megismert max függvénysablont: 


template -class Ts inline T max(r 1hs, T rhs) MG éter 56 





return 1hs 5 rhs ? 1hs: rhs; 4 vittek 


bi 
Gondoljuk végig, mit jelent max függvénysablonunk alábbi két felhasználása: 


int n z max(10, 23); 


COASt char text e MACSADC aZ cdlta elo át TOT kelés 





A két egész típusra teljesen jól működik a fenti max függvénysablon imple- 
mentáció, két sztring összehasonlítására azonban nem alkalmas. Ennek oka 
az, hogy a két char?! mutató közül a nagyobbat adja vissza, vagyis a sztringe- 
ket nem a tartalmazott karakterek, hanem memóriabeli elhelyezkedésük 
alapján hasonlítja össze. Szerencsére van megoldás: függvénysablon-spe- 
cializációt (function template specialization) kell alkalmazni. Ennek az a lé- 
nyege, hogy az általános függvénysablon-definíción kívül bizonyos paramé- 
terbehelyettesítésre az általánostól eltérő implementációt adunk meg. A pél- 
dánkra vonatkozóan ez azt jelenti, hogy megírjuk ugyan a fenti általános max 
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N 


függvénysablont, de emellett meg kell írni egy const char"-ra specializált imp. 


lementációt is. Ez szintaktikailag két módon is megtehető. Az első a , klasszi. 
kus" megoldás: 





Ez esetben a következő szabályok érvényesek: 


e — A függvénysablon elé a template — kifejezést kell írni (a paraméter- 
lista üres). 

a — A függvénysablon neve után € között fel kell sorolni valamennyi sab- 
lonparaméterre vonatkozóan a specializált behelyettesítési értéket, 
vesszővel elválasztva. A példánkra vonatkozóan ez a const char" típus 
megadását jelenti. 


s — Egy függvénysablonhoz több specializáció is készíthető, természetesen 
különböző paraméterbehelyettesítésekkel. 


s A ordító a függvénysablon felhasználásakor egy adott specializációt 
alkalmaz, amennyiben a sablonparaméterek pontosan megegyeznek a 
specializációban megadottakkal. A specializációk villesztése" során a 
fordító semmiféle konverziót nem alkalmaz (így például nem const 
-const konverziót sem). 


e — Függvénysablonokra vonatkozóan csak teljes, valamennyi paraméterre 
vonatkozó specializáció írható (osztálysablonok esetében részleges Specid: 
lizáció is alkalmazható, ennek részleteivel a későbbiekben ismerkedhe: 
tünk meg). 


Ennek megfelelően a 


FERCREES a const char"-ra specializált implementációt alkalmazza A fordjó 
amely az stremp hívásával szabályos sztring összehasonlítást végez), míg 2 


MNGKKENSZER ME SZABS E SE gesoe ez s 0 ztés 


esetében az általános függvénysablon implementációt. 
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114.1. Függvénysabtonok 
A fenti példával kapcsolatban felmerül terül még egy kérdés: miért const char"-ra 
és miért nem char -ra írtunk specializációt. Mint említettük, a specializá. iók 
illesztésekor a fordító a sablonparaméterekre vonatkozóan szigorú tíj Hb 
zőséget alkalmaz. Példánkban a max függvényt az ,abc" és a ,bcd" iiéérálak: 
kal hívtuk meg, melyek típusa const char". Így, ha a char"-ra specializált ver. 
ziót írtuk volna meg, akkor ezen paraméterekre vonatkozóan az általános 
max implementáció hívódna meg! A gondolatmenetet tovább folytatva kérdé- 
ses, hogy ha csak a const char" -ra specializált verziót írjuk meg, akkor char" 
paraméterek esetében alkalmazza-e a fordító a specializált verziót. A válasz 
ez esetben is nem. A tanulság pedig az, hogy a specializációt char: és const 
char" paraméterekre is meg kell írni, másként az adott helyzetnek megfelelően 
meglepő eredményeket kaphatunk a max függvénysablon alkalmazásakor. 


———— —— 
Útmutató: Sablonspecializáció esetén, ha az érintett paraméter mutató típusú, a konstan: 
és nem konstans paraméterekre is írjunk specializációt. gsüle ( 


11.1.2. Példák függvénysablonokra 


Sablonparaméter nemcsak típus lehet, hanem típusos konstans is. Nézzük 
meg az alábbi példát: 





A Sguare függvénysablon sablonparaméterként egy int konstanst vár, amely- 
nek négyzetével tér vissza. A Sguare csak konstans paraméterrel használha- 
tó, hiszen a sablon kifejtése fordítási időben történik. Ez nagyban korlátozza 
használhatóságát, ugyanakkor előnye, hogy a négyzetre emelés — egy közön- 
séges négyzetre emelő függvénnyel szemben — már fordítási időben megtörté- 
nik, ami jelentős futás közbeni sebességnövekedést eredményezhet.7? 





78 A teljes képhez az is hozzátartozik, hogy ha a Sguare függvényt közönséges függvényként 
írjuk meg, és konstans paraméterrel hívjuk, a fordító a teljes hívást jó eséllyel optimali- 
zálja, és a hívás helyére az eredményt helyettesíti be. Bonyolultabb függvénytörzs esetén 
erre kisebb esélyünk lenne, 
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! Korábi ei zt lehetőség van több sablonparaméter 
d; kákzer KEZES éterek megadása során a class helyett a 

megat AHH is használható. Gyakorlásképpen írjunk egy olyan függ. 

Mézenábló it, amely két sablonparaméterrel rendelkezik, és összehasonlítja 77 

EEEN GTEBK memóriabeli méretét: 1-gyel tér vissza, ha az első 

kezáiétetbán megadott típus a nagyobb, —1-gyel, ha a második, és 0-val, ha 


egyenlők. 





A kimenet a következő: 





11.1.3. A hívott függvény kiválasztása 


Amennyiben egy adott függvénynek több implementációja létezik, felmerül a 
kérdés, hogy a függvényhívás során melyik függvény fog meghívódni. A kö- 
vetkező szabályok érvényesek a sorszámnak megfelelő prioritási sorrendben. 


1. Ha létezik olyan közönséges függvény, melynek paraméterei típus 
szerint pontosan megegyeznek, akkor az adott függvény hívódik meg. 


2. Ha létezik olyan függvénysablon, melynek paraméterei típus szerint 
pontosan megegyeznek, akkor az adott függvény hívódik meg. 





——— a a osmtályrábtonak 


típuskonverzióval megegyeznek a paraméterek, akkor az adott függ- 
vény hívódik meg. Az automatikus konverzió nem érinthet sablonpa- 


ramétert. Például a 
template Sclass T5 void MyFunc(double a, T b, T c): 
esetében a b és a c függvényparaméterekre vonatkozóan a korábbi 


szabályoknak megfelelően csak akkor lehetséges az automatikus kon- 
verzió, ha a MyFunc függvénysablont explicit példányosítjuk, vagyis 
míg a MyFunc(10, 10.2, 2); fordítási hibát okoz (a harmadik paramé- 
ternél automatikus intődouble konverzióra volna szükség), az expli- 
cit példányosított MyFuncsdouble:(10, 10.2, 2); hívás lefordul. 


11.2. Osztálysablonok 


A 3.5.2. Dinamikus adattagok támogatása fejezetben ismertettünk egy olyan 
IntFifo osztályt, amely int típusú elemeket tud tárolni. Egy ettől némiképp el- 
térő" IntFifo osztály implementációjának forráskódja a következő: 





"4 Az itt ismertetett IntFifo implementáció körbufferként működik. 














11. fejezet: Cr sablonok 













size) 2 size); 





b lehet a hibát kivétel dobásával. 


y A ma 
new item, the FIFO is full." cc endi; 
t 1 


a. 





ilet végére értünk, de nincs tele 
" vett ki elemet), akkor 


y FIFO." cc endi; 


; e) X size); 
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Az osztályt nem véletlenül neveztük ez esetben IntFifo-nak: ez az osztály int tí- 
pusú elemeket tud tárolni. Amennyiben olyan FIFO osztályra van szükségünk, 
amely például char" típusú elemeket képes tárolni, akkor két megoldási lehető- 
ség közül választhatunk. A meglevő IntFifo osztályról másolatot készíthetünk, 
a másolatot megfelelően átnevezzük (például PCharFifo-ra), az int helyébe a 
megfelelő helyeken char"-ot írunk. A megoldás hátránya egyrészt, hogy mun- 
kaigényes, de sokkal nagyobb baj, hogy a jövőben a FIFO működését érintő 
bármilyen módosítást két helyen kell elvégezni. A rutinos fejlesztők jól tudják, 
hogy a kódduplikálás a programozók egyik legősibb ellensége. A másik megol- 
dás alapja az, hogy elemtípusnak void" mutatót használunk, és ezzel mutatunk 
a tényleges elemekre. Ekkor elvileg tetszőleges típusú elemet tárolhatunk ben- 
ne, ez a megoldás azonban sok sebből vérzik. Egyrészt egyszerű típusok eseté- 
ben borzasztóan körülményes használni, másrészt az elemek elérése a Fifo osz- 
tály felhasználói számára nem típusbiztos (type safe). A részletek mellőzésével 
ezt az alábbi kódrészlet illusztrálja: 
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A problémát az utolsó sor okozza. Amikor kiveszünk a Fifo-ból egy elemet a 
Get metódussal, akkor void"-ként kapjuk vissza. Ezt a pointer felhasználása 
előtt explicit konvertálni kell Persont-ra. Amennyiben véletlenül rossz típusra 
konvertáljuk a Get által visszaadott értéket, a kód minden figyelmeztetés 
nélkül lefordul, futás közben fog rosszul működni a program, és értelmes hi. 
baüzenetet, sajnos még ekkor, futás közben sem kapunk. Amellett, hogy nagy 
a hiba lehetősége, körülményes is minden esetben elvégezni a konverziót. 

A fenti probléma megoldását az osztálysablonok alkalmazása jelenti. 
Az int típusú elemeket tárolni képes IntFifo osztályt osztálysablonná alakítva 
általánosíthatjuk, melyben az elemek típusát nem kötjük meg, hanem sab- 
lonparaméterként definiáljuk. Az osztálysablon esetében a konkrét elemtí- 
pust utólag, az osztálysablon felhasználásakor adhatjuk meg. 


11.2.1. Osztálysablonok írása 


A következőkben azt vizsgáljuk meg, milyen lépésekben lehet /ntFifo osztá- 
lyunkat osztálysablonná átalakítani. A bemutatott kódrészleteknél kiemelt 
szöveggel jelenítjük meg az adott lépésnél az eredeti IntFifo osztályhoz képest 
eszközölt változtatásokat. 


1. lépés - Osztálydefinícióból sablondefiníció 


A fordítónak jelezzük, hogy nem közönséges osztály, hanem osztálysablon de- 
finíciójáról van szó. Ehhez a template kulcsszót kell használni: 





Ennek megfelelően az osztálysablon-definíciót a template kulcsszóval kell 
kezdeni. A template kulcsszót követően — 5 között kell felsorolni a sablonpa- 
ramétereket, vesszővel elválasztva. A paraméterekre vonatkozó szabályok 
megegyeznek a függvénysablonok esetében megadottakkal, ezeket az alábbiak- 
ban megismételjük. Példánkban egy sablonparamétert használunk, ennek az 
ItemType nevet adtuk. Az ItemType paraméter esetünkben egy típust jelöl, 


amit a class kulcsszóval jelzünk a for. 


dító számára. A class helyett a typename 
kulcsszó is alkalmazható. Bármelyiket is h. j éter ek- 
kal namtánkbtálő yiket is használjuk, az adott paraméter el 


hanem tetszőleges típus lehet. Sablon é ő 

1 ú paraméter kons: 
sát lehet, melynek használatára később fogunk példát mutatni. Az IntFifo 
es 8 általánosított formájában értelemszerűen Fifo-ra neveztük át. Míg a 
ggvénysablonok esetében betűvel jelöltük a sablonparamétereket (T, U 


stb.), itt beszédesebb, célszerűen a é álá ó 
5 Paraméter fi ú evet 
használtunk (ItemType, mint elemtípus). DSE ESZÉN 7 





11.2. Osztálysablonok 


2. lépés - Sablonparaméterek bevezetése 


Ebben a lépésben mindenhol, ahol eddig az int ,bedrótozott" típust használ. 
tuk az elem típusára vonatkozóan, az Item Type paramétert szerepeltetjük: 


template cclass Itemrypes 
class Fifo 
1 
Itemrypet pata; 
int size; 
int count; 
int currentPos; 
public: 
FifoCint size -— 100): pData(NULL), size(size), 
; count(0) , currentPos(0) 


poata - new Itemrype(size]; 
J 
Fifo(Fifos fifo) 


1 
pData : new Itemrype(size); 

; 

void Put(Xtemrype item) 

hú 

t3 

bool Get(Itemtypeg item) 

1 

5 d 

pt Ej 

3. lépés - Nem implicit inline definiált tagfüggvények szintaktikája 
Amennyiben a tagfüggvények implementációját nem az osztálydefiníciós rész- 
ben, implicit inline módon kívánjuk megadni, a következőképpen tehetjük meg: 


template cclass ItemTrypes 
class Fifo 


1 


void Put(Itemrype item); 
bool Get(ItemTypeg item); 
h 





// A Put tagfüggvény definíciója 
template cclass ItemTrypez aes] 
void FifocdItemType; : :Put(ItemType item) 
1 vé 


gé988 


zépt 
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A kódrészlet a Put és a Get tagfüggvény definiálását szemlélteti, a definíciót a 
többi tagfüggvény és a konstruktorok esetében is hasonló módon lehet meg- 
adni. Valamennyi tagfüggvény-definíció előtt a template kulcsszót kell hasz- 
nálni, és c 5 között fel kell sorolni a template paramétereket: , template cclass 
ItemType2". Ennek formátuma pontosan megegyezik az osztálydefiníció ese- 
tében használttal (lásd 1. lépés). Ezen túlmenően az osztály neve után £ 5 kö- 
zött vesszővel elválasztva fel kell sorolni a sablonparaméterek nevét: 
, FifosgltemTypez::". Vegyük észre, hogy itt csak a paraméter nevét adtuk meg 
(ItemType), a class, illetve a typename kulcsszót nem írtuk a paraméternév 
elé. Ez a szabály úgy is megmaradhat bennünk, hogy Fifo helyett Fifosltem- 
Type2-ot kell írnunk. De vigyázzunk, a konstruktor és a destruktor nevének 
megadására ez az átalakítás nem érvényes: 





Ez így logikus, hiszen a konstruktor valójában egy speciális tagfüggvény, és a 
többi tagfüggvény is az eredeti nevén szerepel (például a Fifo::Put-ból sem 
lesz FifosltemType2::PutsltemType?). 

, Míg a közönséges osztályok esetében az osztálydefiníciós részt .h fejléc- 
fájlba, a tagfüggvények definícióját .cpp forrásfájlba szokás tenni, osztálysab- 
lonok esetében a tagfüggvények definícióját is a fejlécfájlba kell tenni! Ennek 
okait a 11.2.8. A sablonok fordítása fejezet fejti ki részletesen. 


4. lépés - Osztálynév helyett osztálynév és sablo: éterek 
szerepeltetése a típusként való felhasználás Sr zúdátá 


Azokon a helyeken, ahol a Fifo osztálysablont metódusparaméterként, tagvál- 
a e e ált régebbi fordítók esetében fel 
sorolni a sablonparaméterek neveit vesszővel elválasztva (a class, illetve 

a typename kulcsszó nélkül). Fifo 
klet ak esetében a másolókonst- 





EE EG OSKÉNYEÜlotők 





Mint említettük, ezen szabály (4. lépés) alk: 
modern fordítók esetében nincs rá szüksé: 
73 Ki ri 8- U! i 
hogy ha régebbi forráskódban látjuk az mikálüszésát ; TEkeÉse, TÖják sb 
int látható, alapvetően két-három átalakítási lé észíthetjük a 
Fifo osztálysablont, a teljes Fifo forráskód a kivéleátes S ázánkálet EE a 


almazása nem kötelező, hiszen a 
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A következőkben azt mutatjuk be, hogyan lehet felhaszi érik 
sablont. Az alábbi kódrészlet egy int típusú elemeket Kérés a Fifo júpet 


egy char elemeket tárolni képes fifo2 objektum létrehozását mutatja be: 


A felhasználás során az osztálysablon neve után c 5 között kell megadni a 
sablonparaméterek behelyettesítési értékét. Esetünkben egyetlen paraméter 
van, az ItemType, vagyis az elemek típusa: az első esetben (fifo1 objektum) int 
típust, a második esetben (fifo2 objektum) char típust adtunk meg. Az osz- 
tálysablonok felhasználására vonatkozóan a legfontosabb szabály a követke- 
ző: az osztálysablon a paraméterek megadása (vagyis a sablon kifejté- 
se, példányosítása) után ugyanúgy használható, mint egy közönséges 
osztály. Másképpen fogalmazva: ahol a kódban osztálynév szerepel- 
het, ott szerepelhet felparaméterezett osztálysablon is. A fenti kódban 
ez egyszerűen abban nyilvánult meg, hogy két objektumot lokális változóként 
hoztunk létre. További példákat láthatunk az alábbiakban: 











Felmerül a kérdés, hogy valóban tetszőleges típus megadható-e a Fifo eseté. 
ben sablonparaméterként. A választ a Fifo osztálysablon forráskódjának ala. 
pos áttanulmányozásával kapjuk meg: 


.  Arkonstruktorok 
pData - new ItemTypelsizej; 
sora arra épít, hogy az ItemType típusnak van alapértelmezett (para. 
méter nélküli) konstruktora. 


e A Put tagfüggvény hívásakor meghívódik az IemType másolókonst. 
ruktora, így a másolókonstruktornak jól kell működnie az ItemType 
típusra. Amennyiben a Put tagfüggvényt az alábbiaknak megfelelően 
úgy alakítjuk át, hogy referenciaként kapja meg az elemet, nem hívó- 
dik másolókonstruktor: 
void Put(const ItemTypeg- item) f ... ) 

Ha Fifo sablonunkat nem csak egyszerű típusokkal kívánjuk használni, 
ezt az átalakítást a gyakorlatban mindenképpen célszerű megtenni. 


. A másolókonstruktor datafcurrentPost4] - fifo.data[(fifo.currentPos- 
counttitsize) 9 size) sorában, a Put tagfüggvény datafcurrentPos) - item; 
sorában és a Get tagfüggvény item - datal[(currentPos-countisize) 9 
sizeJ; sorában az operator- mindkét oldalán Item Type áll, vagyis az Item- 
Type-ra értelmezett operator—-t használja, így ennek az operátornak 
az ItemType típusra jól kell működnie. 


e A Print tagfüggvény cout cc data[(currentPos-countti-size) "o size] cc 
" "; sora feltételezi a megfelelő adatfolyamba író operátor meglétét: az 
ostreamát operatorss(ostreamg: os, const ItemTypeg a) 
operátornak értelmezettnek kell lennie. 


Összegzésképpen elmondható, hogy Fifo osztálysablonunk a beépített típu- 
sokra jól működik, hiszen automatikusan teljesülnek a fenti feltételek. Ezzel 
szemben saját osztályok, struktúrák esetében némi többletmunkát igényel a 
fenti feltételek teljesítése. A példa felhívja a figyelmet annak fontosságára, 
hogy amikor saját sablont készítünk, mindig pontosan dokumentáljuk, mi- 
lyen megkötések érvényesek az egyes sablonparaméterekre vonatkozóan. 
Másrészt a sablonok készítésekor célszerű arra törekedni, hogy a paraméte- 
rekre vonatkozóan minél kevesebb ilyen megkötés legyen. 

Az osztálysablonok felhasználásával kapcsolatban érdemes megjegyezni, 
hogy amennyiben egy adott módon felparaméterezett osztálysablont többször kí- 


vánunk felhasználni, kényelmes lehet új típusként való bevezetése a typedef-fel: 





———— o - NI osztályattonok 


141.2.2. Bővebben a sablonparaméterekről 


Az eddig bemutatott példákban minden esetében kizárólag tíj 

k pus sablonpa- 
ramétert alkalmaztunk a class, illetve a typename kulcsszó felhasználásával. 
Ám sablonparaméter lehet típusos konstans, valamint osztálysablon is. Az 
alábbiakban valamennyi lehetőséget alaposabban megvizsgálunk. 


Típus sablonparaméterek 
Eddig erre láttunk példákat, az alábbi kődrészletek is ezt illusztrálják: 





A példában az A közönséges osztály. Tegyük fel, hogy a Fifo egy FIFO viselke- 
dést megvalósító osztálysablon (az elemek típusa a sablonparaméter), az Array 
pedig egy tömb viselkedést megvalósító osztálysablon (az elemek típusa a sab- 
lonparaméter). Ekkor a 


HRKETTV EÜ BITOLI EL ÉNEK 


esetében az ItemType beépített típus, int lesz. 
Típus sablonparaméter tetszőleges osztály vagy struktúra is lehet, így 
az A osztály is megadható: 


EZHETFOZÁS fot E ELERT ÉREZTE E Ettől 





Mint korábban is hangsúlyoztuk, a felparaméterezett osztálysablonok már 
közönséges osztályként kezelhetők, így sablonparaméter lehet felparaméte- 
rezett sablon is. Nézzük az alábbi példát: 


Itt a fifo3 egy olyan Fifo objektum, amelynél az elemek típusa Arraycint;. 
Ennek megfelelően elemei olyan Array objektumok, melynek elemei int típu- 
súak. Lényeges, hogy a két 2 között legyen egy szóköz, ugyanis ennek hiá- 
nyában a régebbi fordítók a 22 karaktersorozatot 22 operátorként próbálják 
értelmezni, így fordítási hibát kapunk. Egy másik példa felparaméterezett 
sablonparaméterre: 


UFifő e Fifődints s fifogjj // A 55 között főntös a szóközt 
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Ékes lehet idonk Skonstátbi A korábban bemutatott Fifo osz. 
tálysablont írjuk át úgy, hogy a FIFO méretét is sablonparaméterben lehes- 
sen megadni. A megoldás lényege a következő: 





Típusos konstans az int Size sablonparaméter, melynek a main függvényben 
a 100 értéket adtunk meg. Alternatív megoldásként használhattuk volna a 
const kulcsszóval megadott konstanst: 





p 


Annak, hogy csak konstans adható meg (változó nem) elvi oka van. A sablonok 
a felhasználásuk során fordítási időben fejtődnek ki, így a sablonparaméterek 
behelyettesítési értékeinek már fordítási időben eldönthetőknek kell lenniük. 
Megjegyezzük, hogy a FIFO példánkban a méret sablonparaméterben való 
TA PVÉRZÖRÁKSRS e zkEY ÜLET az ALA Bnlszássezátet 











11.2. Osztálysablonok 
ee ————e e Kék SZ ÁYNOÁRONOK : 


Sablon sablonparaméterekt 


Maga a sablonparaméter is lehet ki nem fejtett sablon, ezt nevezzük sablon sab- 
lonparaméternek. Bár ennek használatával ritkábban találkozhatunk, s a régeb- 
bi fordítók nem is mind támogatják, sok esetben hatékonyan alkalmazható. 


mm ETTE TEVET TETTEK TT 
Feladat: Írjunk egy olyan ContainerProcessor nevű osztálysablont, melynek statikus tagfüggvé- 
nyei különböző műveleteket végeznek a paraméterként megkapott tároló (container) osztályon. 
felejzttkztéstomántata ááá mbásetázésdeazi s Mlsriztszezál zttsésztoázsszlédee ds Ín ate sztnizétztretozt es áhaoszztáézen adott ddtszzászsn áscsaszóttltlli 


Kiinduló megoldásunk még nem használ sablon sablonparamétert: 
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11. : Ces sablonok 





A kimenet a következő: 


The content of the FIFO: 10 11 
Items after reversing: 
The content of the FIFO: 11 10 


A megoldást úgy tettük általánossá, hogy a ContainerProcessor-t olyan osz- 
tálysablonként írtuk meg, amelynél paraméterként lehet megadni a tároló 
osztályát (ContainerType), valamint az elemek típusát (ItemType). A main 
függvény arra mutat példát, hogy a korábban ismertetett Fifo osztálysablon 
esetében hogyan használható a ContainerProcessor ReverseContainer tag- 
függvénye az elemek sorrendjének megfordítására. A Fifo esetünkben int 
típusú elemeket tartalmaz. A ReverseContainer tagfüggvény nemcsak a Fifo 
tárolóosztállyal, hanem tetszőleges olyan osztály és felparaméterezett osz- 
tálysablon esetében használható, amelyre igaz a következő: van int Count), 
Put(ItemTypeg), Get(ItemTypeg-) tagfüggvénye, és ezek a Fifo osztályéval 
megegyezően működnek (a Count az elemszámot adja vissza, a Put beteszi a 
paraméterként kapott elemet utolsóként, a Get pedig a legelsőként betett 
elemet kiveszi, és azzal tér vissza). Ezek a megkötések azért élnek, mert a 
ReverseContainer tagfüggvény implementációja felhasználja őket, mint az a 
fenti kódrészletben látható. 

Ha alaposabban megnézzük a ReverseContainer használatát a main függ- 
vényben, a Container Type paraméter megadásakor Fifocint2-et adtunk meg, és 
nem Fifo-t. Ezt kötelezően így kellett tennünk, hiszen a ContainerType para- 
méternek csak egy teljes típust lehet megadni, a sablonparaméter előtt ugyanis 
a class kulcsszó szerepel! Ennek megfelelően vagy közönséges osztály, vagy fel- 
paraméterezett osztálysablon adható meg. Ugyanakkor a Fifosint2 esetében az 
int elemtípus megadását fölöslegesnek érezzük, hiszen a második sablonpara- 
méterben (ItemType) úgyis meg kell adni. Ez hibalehetőséget is rejt magában: 
amennyiben a ReverseContainer hívásakor a Fifo tárolóosztály elemtípusának 
más típust adunk meg, mint az ItemType paraméter, az fordítási hibát vagy hi- 
bás működést is eredményezhet: 


A megoldást a sablon sablonparaméterek alkalmazása jelenti. Ez esetben 
maga a sablonparaméter is sablon, pontosabban egy fel nem paraméterezett 
osztálysablon lesz. A megfelelően átalakított ContainerProcessor osztálysab- 
lon forráskódja a következő: 
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Először koncentráljunk a sablon sablonparaméterek definiálásának szintak- 
tikájára. A vonatkozó kódrészt megismételjük: 

















11. fejezet: Css sablonok 





Példánkban egy sablon sablonparamétert alkalmaztunk, a ContainerType-ot. 
A sablon sablonparaméterekre vonatkozóan pontosan meg kell adni, hogy az 
adott paraméter helyébe milyen paraméterezésű osztálysablonok helyettesíthe- 
tők. Ennek megfelelően a sablon sablonparamétereket a templatec..3 class 
kulcsszóval kell megadni, ahol a c 2 között vesszővel elválasztva név nélkül fel 
kell sorolni a sablonparamétereket. Ez azt jelenti, hogy ha az adott paraméter 
típus, akkor a class vagy a typename kulcsszót kell beírni, ha konstans, akkor 
annak típusát. Most nézzük, mit jelent ez a példánkra vetítve: ContainerType 
paraméterünk helyébe olyan osztálysablonok helyettesíthetők be, melyeknek 
pontosan egy sablonparamétere van, amely típus. Ezt a definícióban a 


templatesclassz class ContainerType 


megadásával jelezzük. Egy másik példa sablonparaméter-definícióra: a template 
2elass, int, classz class TemplA esetében a TemplA olyan sablonparamétert jelöl, 
amelynek a helyébe olyan osztálysablonok helyettesíthetők, melyek első paramé- 
tere típus, a második egy int típusú konstans, a harmadik megint típus. A sablon 
sablonparaméterek megadásának szintaktikáját könnyű megjegyezni, ha észre- 
vesszük, hogy pontosan úgy néz ki, mint egy osztálysablon-definíció a paramé- 
ternevek elhagyásával. Nézzük például az alábbi osztálysablon-definíciót: 


Ha ilyen osztálysablonokat szeretnénk sablonparaméterben megadni, akkor a 
sablonparaméter megadásakor hagyjuk el a paraméterneveket (az előző kód- 
részletben a vastagon szedett részeket): 








A ContainerProcessor osztályhoz visszatérve vizsgáljuk meg alaposabban a 
ReverseContainer tagfüggvény paraméterét: 


Az eredeti verzióban ContainerTypeg: volt a paraméter típusa, itt viszont 
ContainerTypesltemType:é szerepel. Ha ismerjük azt a szabályt, hogy függ- 
vényparaméter csak teljes értékű típus lehet (osztály vagy felparaméte- 
rezett osztálysablon), akkor nem csodálkozunk ezen: mivel az átalakított pél- 
dánkban a ContainerType osztálysablon, a függvényparaméter megadásakor 





A sablon sablonparaméter alkalmazásával pedig így: 


. ContainerProcessorcFifo, ints::ReverseCOntainer (ifj 


A sablon sablonparaméter alkalmazásának előnye itt jelenik meg: az elemtí- 
pust (int) csak egyszer kellett megadni, így nem eshetünk abba a hibába, 
hogy figyelmetlenségből eltérő elemtípusokat adunk meg. 


11.2.3. Alapértelmezett sablonparaméterek 


Mind függvénysablonok, mind osztálysablonok esetében lehetőségünk van 
alapértelmezett értéket adni a sablonparamétereknek. Például: 





Az ItemType paraméternek az int alapértelmezett értéket adtuk. Így, ha a Fifo 
osztálysablon felhasználásakor nem adunk neki értéket, akkor az int értéket 
veszi fel. Erre láthatunk példát az intFifo objektum létrehozásakor. A charFifo 
objektum esetében már megadtuk a char típust sablonparaméterként, ekkor az 
ItemType paraméter char lesz. 

Az alapértelmezett sablonparaméterek megadására ugyanazok a szabá- 
lyok érvényesek, mint az alapértelmezett függvényparaméterekre vonatkozóak: 
jobbról balra sorban haladva kihagyás nélkül tetszőleges számú paraméter- 
nek adható alapértelmezett érték. A szabály alkalmazását az alábbi kódrész- 
letek illusztrálják: 
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Az alapértelmezett sablonparaméterek lehetővé teszik olyan sablonok készi. 
tését, melyek széles körben testre szabhatók (mivel több sablonparaméterrel 
rendelkeznek), ugyanakkor a legtöbb helyzetben (az alapértelmezett paramé. 
terek esetében) egyszerűen felhasználhatók. Kitűnő példa erre a Szabványos 
C-t Könyvtár basic. string osztálysablonja, amely sztringek rugalmas kezelé- 
sét teszi lehetővé. Ennek definíciós fejléce a következőképpen néz ki: 





Mint látható, a basic. string három sablonparaméterrel is rendelkezik: 


e — CharType: a sztring karaktereinek típusa. Tipikusan char, illetve Uni- 
code esetében wchar t. 


e  Traits: olyan, a karakterjellemzőket tartalmazó osztály, melyet a 
basic. string tagfüggvényei használnak fel többek között a karakterek 
másolására és összehasonlítására. Az alapértelmezett char. traits az 
összehasonlítás során megkülönbözteti a kis- és a nagybetűket (case 
sensitive). Amennyiben ez a viselkedés nem felel meg számunkra, 
megfelelő saját ,traits" osztály megadásával lehetőség van a kis- és 
nagybetűket az összehasonlítások során meg nem különböztető basic. 
string objektumok létrehozására. Annak természetesen alaposan utá- 
na kell néznünk a basic string dokumentációjában, hogy az itt meg- 
adott ,traits" osztálynak pontosan milyen publikus tagfüggvényekkel 
kell rendelkeznie. 


.,  Allocator: olyan osztály, amely a dinamikus helyfoglalást végzi a 
sztring által tartalmazott karakterek számára. Szükség szerint saját 
helyfoglaló osztály is megadható, de ezt a legritkább esetben 
megtenni. 

A Szabványos Cs-t Könyvtárnak részei még az alábbi típusdefiníciók, mely: 


nek felhasználásával egyszerű char és wchar. ű sztringeket rendkívül 
KS BLÉ tátve -t elemű sztringe: 
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Az alábbi példák azt szemléltetik, hogy alapértelmezett viselkedésű sztring 
objektumok egyszerűen létrehozhatók, ugyanakkor a sablonparaméterek exp- 
licit megadásával a speciális igényeket kielégítő sztring objektumok is példá- 
nyosíthatók: 





11.2.4. Pointerek, referenciák és konstansok, 
mint sablonparaméterek 


Ha bizonyos, széles körben használt osztálykönyvtárak sablon tárolóosztá- 
lyainak definícióit megnézzük, furcsának tűnhet, hogy az elemek típusa mel- 
lett azt is meg kell adni sablonparaméterként, milyen típusként kezeljék a 
tagfüggvények paramétereikben az elemeket. Ennek természetesen komoly 
oka van, amit a korábbiakban ismertetett Fifo osztálysablon megfelelő átala- 
kításával világítunk meg: 
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11. fejezet: Css sablonok 


Mint látható, a Put tagfüggvény paramétereként a ParamType sablonpara- 
métert használjuk, a többi helyen marad az ItemType. Amennyiben az elem- 
típus, vagyis az ItemType összetett, nagyobb méretű objektumokat eredmé- 
nyező típus, akkor ezeket az objektumokat referenciaként érdemes paramé- 
terben átadni a függvényeknek annak érdekében, hogy elkerüljük a paramé- 
terátadáskori másolat készítését, s így a másolókonstruktor hívását. Ezt úgy 
tudjuk elérni, hogy a ParamType sablonparaméternek ItemTypeg--t (ItemType 
referenciát) adunk meg: 





Vagy egyszerűbben, kihasználva, hogy a ParamType paraméternek Item- 
Typeg--t adtunk meg alapértelmezett értékként: 





Mindkét esetben a Put tagfüggvény ParamType paramétere a sablon kifejté- 
sét követően stringé lesz. Ha az elemtípus, vagyis az ItemType egyszerű be- 
épített típus, vagy kisméretű objektumok osztálya, akkor a referencia alkal- 
mazása csak lassítja a működést. Ez esetben ParamType-nak magát az 
ItemType-ot adjuk meg: 


11.2.5. Tagfüggvénysablonok 


Függvénysablonok nemcsak globális függvények lehetnek, hanem tagfüggvé- 
nyek is. Ezek közönséges osztályok vagy osztálysablonok tagfüggvényei egy- 
aránt lehetnek. Együttesen tagfüggvénysablonoknak nevezzük őket. Az 
alábbiakban az előbbire látunk példát: 











sablonunk T paramétere az U osztálysablon-paraméterektől telj a 
lenül megadható lenne (például az egyik lehetne int, a másik fede double 3 

Tagfüggvénysablon lehet konstruktor is. Erre vonatkozóan azonban van 
egy megkötés: a sablonkonstruktor sohasem fog másolókonstruktorként vi. 
selkedni, ezt mindig meg kell írni közönséges konstruktor formájában (vagy a 
beépített, ,bitenként" másoló konstruktor hívódik meg). A konverziós konst- 
ruktorokra vonatkozóan nincs ilyen megkötés. 


11.2.6. Az osztálysablonok és az öröklés 


Az alábbiakban megvizsgálunk néhány olyan öröklési esetet, amelyekben osz- 
tálysablon is szerepel. Kiindulásképpen a következő definíciókat fogjuk fel- 
használni: 





A ClassA közönséges osztály, a TemplA két sablonparaméterrel rendelkező osz- 
tálysablon. Bár az alábbi esetek első ránézésre bonyolultnak tűnhetnek, egy 
szabály ismeretében fejből is könnyen képesek lehetünk létrehozásukra. Ez pe- 
dig a következő: ősosztályként minden esetben csak közönséges osztály 
vagy felparaméterezett osztálysablon használható (nem felparamétere- 
zett osztálysablon nem). A dolog rugalmasságát az adja, hogy amennyiben az ős 
osztálysablon, ennek felparaméterezéséhez a leszármazott osztály sablonpara- 
métereit is felhasználhatjuk! Minderre rövidesen példát is mutatunk, előbb 
azonban az egyszerűbb eseteket ismertetjük. Az alábbi példában a TemplA-ból 
mint ős osztálysablonból egy közönséges osztályt származtatunk le: 


Az ős osztálysablonnál a T1 paraméter helyébe int, a T2 helyébe ClassA osz- 
tályt helyettesítettünk. Szabályunknak megfelelően az ősosztály megadása: 
kor felparaméterezve használtuk az osztálysablont. 
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11. fejezet: Cst sablonok 
Az alábbi esetben a ClassA-ból mint közönséges osztályból osztálysablont 
származtatunk le: 


template cclass T1 
class TemplB: public classA k 


TI t; // T1 típusú tagváltozó 
h 
A legösszetettebb esetnek az osztálysablonból új osztálysablon leszármaztatá- 
sa tekinthető. Például: 


template class T3, class T42 
class Templc: public Templacint, T3- 


T3 t;  // T3 típusú tagváltozó 


h 


A leszármaztatatott TemplC osztálysablonnak két paramétere van: 73 és T4. 
A szabálynak megfelelően az ős sablonosztályt itt is felbparaméterezve hasz- 
náltuk fel. A T1 paraméternek a fix int értéket adtuk, a T2-nek azonban a le- 
származtatott osztály T3 paraméterét adtuk , tovább", így az ősre vonatkozóan 
ez a továbbiakban is paraméterezhető marad! A példában a leszármaztatott 
osztályban T3 és T4 paraméternevek helyett a 77-et és a T2-t is használhat- 
tuk volna, ez nem jelentett volna ütközést az TemplA ősosztály azonos nevű 
paramétereivel. 

Egy másik, gyakorlatiasabb példát a korábbi fejezetekben ismertetett Fifo 
osztálysablon felhasználásával mutatunk be. Specializáljuk a Fifo viselkedé- 
sét úgy, hogy az elemek típusa a továbbiakban is megadható legyen! A meg- 
oldás alapja a következő: 












template eclass I! a 
gi SpecFifo: public Fifocrtemrypes 


11 A specializált viselkedést megvalósító tagfüggvények 





A legsz élsőségesebb esetek közé tartoznak azok az osztálysablonok, melyek 
ősosztályát sablonparaméterben lehet megadni: 


template 


class 
h egots 5 






A megoldás többek között lehetővé teszi, hogy osztálysablonunk interfészé 
(publikus függvényeinek halmaza) utólag, az osztálysablon felhasználásakor 
legyen megadható. k8 
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11.2. Osztálysablonok 
11.2.7. Osztálysablon-specializációt 


A 11.1. Függvénysablonok részben tárgyalt max függvénysablon esetében láttuk. 
hogy általános implementációja nem volt megfelelő a chart típus esetén, így érté 
függvénysablon-specializációt készítettünk. Erre osztálysablonok ssÖlia van 
lehetőség. Előfordulhat ugyanis, hogy egy adott osztálysablon esetében bizonyos 
paraméter-kombinációkra vonatkozóan nem megfelelő az adott osztálysábloa 
működése. 





Feladat: Elsődleges feladatunk egy olyan univerzális ueuedCommManager osztálysablon 
megírása, melyet alkalmazások közötti kommunikációra tudunk felhasználni. Az osztálynak a 
terheléskiegyenlítést támogató üzenetsor alapon kell támogatnia. 





Vegyük kiindulásnak az alábbi osztálysablonvázat: 


template cclass OueueType, class CommHandlerz 
class OueuedcommManager 
1 
// FIFO üzenetsor a fogadott üzeneteknek. 
// A típusa sablonparaméterként adható meg. 
OueueType gueue; 
// Az alacsony szintű kommunikációért felelős objektum. 
// A típusa sablonparaméterben adható meg. 
CommHandler commHandler; 


// Egy háttérszálból hívandó függvény, amely fogadja a küldött 
// adatokat, az adatok alapján Message típusú objektumot 
// készít, és beteszi a sorba. 
void runO 
d 
Message" pMsg; 
char buff[MAX MESSAGE. SIZE]; 
commHandler.InitO; 
while (commHandler.Read(buff)) 
( 
pMsg - new Message(buff); 
gueue.Put( pMsg ); 
J 
J 
public: 
// Üzenet küldése 
void Send(Messaget msg) 


commHandler . Send(msg-2GetData0) , msg-sGetcharCount 0); 
J 


// A következő üzenet kivétele a sorból. NULL-1a1 tér vissza, ha 
// üres a sor, 
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A OueuedCommManager a fogadott, de még ki nem olvasott adatokat üzenet- 
sorba teszi, az üzenetsor típusa a OueueType sablonparaméterben adható 
meg. A OueuedCommManager tetszőleges kommunikációs formát támogathat 
(például megosztott memória, socket alapú kommunikáció, soros vonali kom- 
munikáció stb.). A paraméterezhető megoldás alapja az, hogy a dueuedComm- 
Manager az adatok küldéséhez és fogadásához a CommHandler sablonpara- 
méterben megadott osztályt használja. Az egyes kommunikációs formákhoz el 
kell készíteni a megfelelő CommHandler osztályokat. Az implementációs 
részletek számunkra nem érdekesek. 

Most tegyük fel, hogy a megosztott memória alapú kommunikációhoz már 
van egy SharedMemoryHandler osztályunk, viszont a fenti OueuwedComm- 
Manager implementáció nem megfelelő, ha CommHandler helyébe a Shared- 
MemoryHandeer osztályt helyettesítjük"6 (mert például nincs Init, Read és 
Send tagfüggvénye, amire a fenti implementáció épít). Erre az esetre egy 
GueuedCommManager osztálysablon-specializációt (template specialization) 
írhatunk: 





Az osztálysablon-specializáció megírására a következő szabályok érvényesek: 


s — Az osztálysablon neve előtt a template kulcsszó után £ 5 között csak 
azokat a maradó sablonparamétereket kell felsorolni, amelyeket a to- 
vábbiakban is paraméterként kívánunk kezelni, vagyis amelyeket 
nem kívánunk specializálni (megkötni). A fenti példában ilyen para- 
méter a OueueType. 


SES ee EST 
" Ez azzal analóg, hogy a korábbiakban tárgyalt max függvénysablon általános implemen- 


tációji íj é ializáci 
kozáédásen volt megfelelő a char" típus esetén, így erre függvénysablon specializációt ké- 


248 





EE SAL Se 
e  Aosztálysablon neve után c 5 között fel áörölnis dlsáka 
lonparamétert: a nem specializáltakat a az iszssggz 


e A fordító a sablon felhasználásakor mindi a tehétői Égi ri 
Tészkedő sátlórverüőé átkelt ÁMT cespeciáliásbb il 


e A fordító az illesztés során semmiféle konverziót nem alkalmaz (így 
például const ca nem const konverziót sem). 


A fenti példát részleges sablonspecializációnak (partial template speciali- 
zation) nevezzük, mert csak részben köti meg a sablonparamétereket. Lehe- 
tőség van természetesen a paraméterek tetszőleges kombinációjára vonatkozó 
specializált OueuedCommManager megírására. Ha valamennyi sablonpara- 
métert megkötjük, azt teljes specializációnak ((full template specialization) 
nevezzük. Erre példa lehet, ha OueuedCommManager osztálysablonunkat a 
RueueTypezSpecFifo, CommHandler-SharedMemoryHandler paraméter-be- 
helyettesítésekre vonatkozóan specializáljuk: 





Mint látható, a szabályoknak megfelelően a template kulcsszó után most nem 
adtunk meg egyetlen paramétert sem, mert valamennyit specializáltuk, vagyis 
mindnek konkrét típust adtunk meg. Most tekintsük meg az alábbi felhasz- 
nálási példákat: 





A fordító a szabályoknak megfelelően mindig a legspeciálisabb illeszkedő imp- 
lementációt alkalmazza. A gm!1 esetében ez a teljesen specializált, am2 esetében 
a részben specializált, míg gm3 esetében az általános implementációt jelenti. 























11. : Cst sablonok 


11.2.8. A sablonok fordítása 


A sablonok használatával kapcsolatban alapvető fontosságú annak ismerete, 
hogy a sablonok fordítási időben fejtődnek ki. Amikor a fordító a fordítás 
során először , találkozik" az osztálysablon egy adott példányosításával, megfe. 
lelően behelyettesíti a sablonparamétereket, és legenerálja a behelyettesítésnek 
megfelelő kódot. Sőt, ezen állításunk tovább pontosítandó: az osztálysablonok 
esetében a kódgenerálás tagfüggvényenként történik, vagyis egy tag- 
függvény kódja csak akkor generálódik le, ha legalább egy helyen használjuk. 
Vizsgáljuk meg a korábban bevezetett Fifo osztálysablont: 





Amikor a fordító a 


sorhoz ér, veszi a Fifo osztálysablont, az ItemType paraméter helyébe int-et 
helyettesít (mert a fifol típusa Fifocint:), legenerálja az alapértelmezett 
konstruktorának a kódját, és ennek hívására vonatkozóan generál kódot. A 


sorhoz érve a fordító veszi a Fifo osztálysablont, az ItemType paraméter he- 
lyébe int-et helyettesít, legenerálja a Put metódus kódját, és most ennek hívá- 
sára vonatkozóan generál kódot. A 


sor esetében a Put kódja (ItemType-int esetére) már le van generálva, Így 
csak ennek hívására vonatkozó kód generálódik (a Put kódja már nem). A 











—G——— IT osztálysatonok 


sorokhoz érve a fordító az ItemType 3 
(mert a fifo? típusa Fifosdouble:), ötózssssáts kötés dotble-t összgiset 
ruktor és ennek hívásának, majd a Put metódus és ennek fenét ekádlék e 
A sablonok ezen fordítási mechanizmusának számos kellemes és Me 
metlen következménye van, ezeket fogjuk a következőkben áttekinteni, e- 


Optimalizáció 


Ha egy adott osztálysablon tagfüggvényét sehol sem használj 

legenerálódni a kódja:Az optimalizáció örvendetee öl öéle etes TB 
rált kód mérete lényegesen kisebb lehet, mint ha közönséges osztályokkal vagy 
függvényekkel dolgoznánk. Gondoljunk csak bele: ha van egy sok osztálysablont 
tartalmazó osztálykönyvtárunk, és ebből egyetlen osztály egyetlen tagfüggvényét 
használjuk, akkor mindössze ennék kódja generálódik le! Így alkalmazásunk a 
háttértáron és a memóriában is a lehető legkisebb helyet foglalja el. 


Kódburjánzás 


Ha egy sablont — legyen az függvénysablon vagy osztálysablon — több paraméter- 
kombinációval használunk (például Fifosint2, Fifocdouble: stb.), valamennyire 
vonatkozóan legenerálódik a sablon tagfüggvényeinek kódja, ami a generált kód 
méretének növekedéséhez vezet. Ezt szokás kódburjánzásnak vagy kódfelfú- 
vódásnak (code bloat) nevezni. Bár ez a gyakorlatban ritkán jelent problémát, 
nem árt tudnunk róla. 


Fordítási hibák 


A fordítási modell talán legmeghökkentőbb következménye, hogy a fordítási 
hibák rejtve maradhatnak. Könnyen megeshet, hogy egy osztálysablon 
vagy függvénysablon megírását követően a fordítás során semmilyen hibát 
sem kapunk, és a kód mégis tele van szintaktikai és egyéb hibákkal! Valójá- 
ban nem is várhatunk mást, hiszen mint korábban állítottuk, a sablonok tag- 
függvényei csak akkor fordulnak le, ha használjuk őket! Mindaddig nem es- 
nek át teljes szintaktikai ellenőrzésen. Vegyük Fifo osztálysablonunk fel- 
használásával az alábbi példát: 
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A példában csak a Fifo osztálysablon alapértelmezett konstruktorát és Put 
tagfüggvényét használjuk, így a fordító csak ezeket fordítja le, az összes többi 
tagfüggvény fordítási hibája rejtve marad. Persze felmerül a kérdés, hogy mit 
is lehet tenni azon túl, hogy valamennyi osztálysablon valamennyi tagfügg. 
vényét meghívjuk a fordítás kikényszerítésének céljából. A megoldást az osz. 
tálysablonok explicit példányosítása (explicit template instantiation) adja, 
Az explicit példányosítás a megadott paraméterekkel valamennyi tagfügg- 
vényre vonatkozóan kikényszeríti a kód generálását. A szintaktika a következő: 





Ez a sor a Fifo osztálysablont az ItemType-int paraméter-behelyettesítéssel 
példányosítja. 

Függvénysablonok esetében is lehetőség van az explicit példányosításra. 
Ehhez az adott függvénysablont a template kulcsszót követően az adott pa- 
raméter-behelyettesítésekkel deklarálni kell: 





Következzen néhány kapcsolódó észrevétel: 


s A fenti példában a max függvény inline, így az explicit példányosítás 
legenerálja ugyan a kódját, a hívás helyére azonban, amennyiben le- 
hetséges, a törzse fog behelyettesítődni. 


e — Az explicit példányosítás jól használható arra, hogy , előcsalogassuk" 
a fordítási hibákat, de a kód részletes tesztelését önmagában nyilván- 
valóan nem oldja meg. 


e Az explicit példányosítást sablon osztálykönyvtárak készítésekor is 
felhasználhatjuk, erre rövidesen visszatérünk. 


. Ha egy sablon a paraméterek adott kombinációjával jól lefordul és jól 
működik, még korántsem biztos, hogy más paraméterek esetén is jól 
fog működni. Pontosan dokumentáljuk a paraméterekre vonatkozó 
megkötéseket, valamint mindig több paraméter-behelyettesítéssel is 
végezzünk tesztelést: beépített és saját típusokkal is, ha mi 
támogatni kívánjuk! 





11.2. Osztálysablonok 
Fejléc- és forrásfájlok 


A közönséges függvények és osztályok esetében 
egyetlen, a 3.3. Adatrejtés fejezetben részletesen 
elv használható igazán: 


nagyobb méretű projekteknél 
ismertetett kódstrukturálási 


e — A függvények deklarációit fejléc- (.h), a definícióit forrásfájlokba tesszük. 


e Az osztályok definícióit (a class MyClass (...); ré: fö 
PGy z "7 részt) fejléc-, es 
vények definícióit forrásfájlokba tesszük. 087 5ETIS A ALTRBÁBB 
Ez az elv sablonok esetében nem használható! A magyarázat alapjául á 
jon az alábbi, a fenti elveket követő kódrészlet: ZS S Lt 
// File: Fifo.h 
template cclass ItemTypez 
class Fifo 


tí 
public: 

void Put(Itemrype item); 
jaj 


// File: Fifo.cpp 
$finclude "Fifo.h" 


// A Put tagfüggvény definíciója 
template cciass ItemTypez 

void FifocItemTypes : : Put(Itemrype item) 
£ 


ssőjá 


// File: main.cpp 
$include "Fifo.h" 
int mainO 
11 
Fifocints fifo; 
fifo.Put(10); 
ő 


A kód fordítási hibát eredményez, és ez nem is lehet másként. Gondoljuk vé- 
gig, mit ,lát" a fordító a main.cpp fájlt feldolgozása során. A preprocesszor ki- 
fejti az ttinclude "Fifo.h"-t , s mivel ez gyakorlatilag egyszerű szövegszerű be- 
helyettesítést jelent, a fordító a következő , fájlon" dolgozik: 


// File: main.cpp 
. [/ File: Fifo.h 
. template cclass ItemTypez 
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Espsosz 





A sablonokról tudjuk, hogy fordítási (és nem linkelési) időben fejtődnek ki. 
Másrészt emlékezzünk: a fordító a forrásfájlokat egyesével dolgozza fel, így a 
main.cpp feldolgozásakor kizárólag a fenti forráskódot látja. Ezzel el is érkez- 
tünk a probléma gyökeréhez: a sablon kifejtéséhez teljes forráskódjának (be. 
leértve a használt tagfüggvények törzsét is) a fordító rendelkezésére kell áll- 
nia! A fenti példában ez a fifo.Put(10); sor feldolgozásakor a Put tagfüggvény- 
re nem teljesül, hiszen az egy másik forrásfájlban, a Fifo.cpp-ben definiált. 
Ennek következtében a linker , Unresolved external symbol ..." vagy hasonló 
hibaüzenetet ad."7 A tanulság pedig az, hogy az osztálysablonok esetében 
a felhasználás során a tagfüggvények definícióját is elérhetővé kell 
tenni a fordító számára. Ezt kétféleképpen tehetjük meg. Az első megoldás 
szerint a tagfüggvényeket az osztálysablon-definícióban , inline módon" defi- 
niáljuk, mint az alábbi példában: 





7 Bizonyára felmerül a Kedves Olvasóban, hogy miért a linker adja a hibaüzenetet, 67 
sablon fordítási időben fejtődik ki. Valójában a színfalak mögött a fordító és a linker "a 
gikus" módon összejátszik a kódburjánzás csökkentésének érdekében. Miről is van 


Ha a sablonok kifejtését tisztán a fordító végezné, akkor a sablonok ugyanazon kód: 
ter-behelyettesítéssel, de több forrásfájlban történő felhasználásának is többszörös 
generálás lenne a következménye. Például a Fifosint2-re vonatkozóan a Put tagfüggéő 
hívása a main.epp és mgueue.cpp forrásfájlokban azt eredményezné, hogy a Put kódje 
futtatható . jeckább Vet reá h TT A raoderú főrdítók ös ÜT ÉSE szerencsére 
megoldják, egotdják, ha ha több forrásfájlban ugyanazon sablonparaméter-behely eltelve 
használunk egy sablont, akkor a vonatkozóan kód a generált kimenet 
ben csak egyszer szerepeljen, és a függvényhívások erre vonatkozóan oldódjanak fel. 
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Közönséges (nem sablon) osztályok tagfüggvényei esetébei i ü 
dás linkelési hibához vezetne a fejlécfájl több forrástálha se izletojeztel 
tén, mert a Put többször is lefordítódna, így a függvény többször definiált len- 
ne. Az osztálysablonok tagfüggvényeinek esetében azonban ez nem okoz prob- 
lémát, a linker ,okosan" mindig az első definíciót teszi a lefordított kódba, és 
a hivatkozásokat is erre vonatkozóan oldja fel. Ugyanez igaz a globális függ: 
vénysablonokra is, a közönséges függvényekkel ellentétben ezek definícióit is 
fejlécfájlokba tehetjük. 


Sablon osztálykönyvtárak 


Ha osztályainkat, illetve függvényeinket több helyen szeretnénk felhasználni 
(például több projektben), vagy esetleg értékesíteni kívánjuk, célszerű egy le- 
fordított osztálykönyvtárat készíteni. Ennek során az osztályok és a függvé- 
nyek forráskódját előre lefordítjuk. Ez statikus könyvtárak esetében általá- 
ban .lib, dinamikusan linkelt könyvtárak esetében operációs rendszertől füg- 
gően .d/l, .so stb. kiterjesztésű állományba történő fordítást jelent. A felhasz- 
nálás során a lefordított osztálykönyvtár mellett csak a globális függvények 
deklarációit és az osztályok definícióit (a tagfüggvények definícióit nem!) tar- 
talmazó fejlécfájlokra van szükség. A felhasználás során include-oljuk a fej- 
lécfájlokat, valamint a linker-rel csatoljuk az osztálykönyvtárat. Ebben a mo- 
dellben a felhasználáshoz a forráskód lényegi részére, vagyis a globális függ- 
vények és a tagfüggvények definíciójára nincs szükség, így gyorsítható a for- 
dítás folyamata, valamint megoldható a forráskód védelme. 

Ez a modell azonban sablonok esetében nem használható! A sablonok 
ugyanis mindaddig nem fordulnak le, amíg nem használjuk őket. Márpedig a 
fenti modellnek éppen az volt a lényege, hogy az osztályokat és a függvénye. 
ket lefordított formában használjuk fel. A sablonok esetében egyszerűen nincs 
mit előre lefordítani! A legtöbb esetben egy dolgot tehetünk: nem fordítunk le 
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előre semmit, hanem  fejlécfájlokban elhelyezett — forráskód 
formájában kae tjél 5 VAY adjuk tovább az osztálykönyvtárat. Egyetlen, 
ritka esetben tudjuk előre lefordítani a sablonokat: ha pontosan tudjuk, mely 
paraméter-behelyettesítésekkel kerülnek majd felhasználásra. Ez esetben 
ugyanis explicit példány osítással ezekre a paraméter-behelyettesítésekre ki. 









kényszeríthetjük a fordított: -kód generálását. 


11.2.9. További osztálysablon technikák" 
Sablonok deklarálása 
A függvénysablonok a közönséges függvényekkel azonos módon deklarálhatók: 





Az osztálysablonok deklarációja megfelel a közönséges osztályok deklaráció- 
jának, természetesen megfelelő sablonszintaktikát alkalmazva. Tekintsünk 
meg az alábbi osztálysablon definíciót: 





Ez esetben az Fifo osztálysablon a következő módon deklarálható: 





Erre például akkor lehet szükség, ha a Fifo osztálysablont a forrásfájl egy ké- 
sőbbi pontján pointer vagy referencia formájában fel kívánjuk használni, és a 
Fifo definíciót tartalmazó fejlécfájl (Fifo.h) include-olása nem jelent megol- 
dást (például a kölcsönös egymásra hivatkozások miatt, ha a Fifo.h is include- 
olja jelen fájlt). 


Sablonparaméterek , publikálása? 


Egy osztálysablon paraméterei alapvetően csak az adott osztálysablonon be- 
lül érhetők el. Egy egyszerű, gyakran alkalmazott trükkel azonban más OsSZ- 
tályok, illetve globális függvények számára is elérhetővé tehetők. A megoldás 
alapelve az, hogy az osztálysablonban a publikálni kívánt paraméterekre 
typedef-fel új típust definiálunk, amit az alábbi példa illusztrál: 
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Most pedig nézzünk egy összetettebb példát az osztálysablonok és a typedef 
használatára, melynek magyarázatát utólag adjuk meg: 
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11. fejezet: Cs sablonok 









bject - objectToLock; 
// Az objektumot zároló függvények hívása 
éőut. ez "GE is acguired. " 2 end; 
Zönjedttekő 3 
8 17 zár feloldása this-sobject-re. 
ú60k cc "Lock is released." cc endi; 
1 
class SinglerhreadedModel 
tte. et 
typedef NoLock Lock; 
56 ZA 
class MultiThreadedmodel 


1 
public: 
typedef ObjectLock Lock; 


h 


template cclass ThreadingModel: 
class MyrTemplate 
1 


public: 
1. DosafeoperationO) 


typename ThreadingModel : :Lock guard(this); 


// A kölcsönös. kizárást igénylő műveletek... Hét 
cout cc "Performing operation" cc endi; ( 


KEY le ezé § 
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A kódrészlet kimenete a következő: 





A példában a cél a MyTemplate osztálysablon olyan kialakítása volt, hogy 
mind egyszálú, mind többszálú környezetben hatékonyan felhasználható le- 
gyen. A gyakorlott programozók jól tudják, hogy a közös erőforrásokhoz való 
párhuzamos (itt több szálból való) hozzáférés esetén meg kell oldani a kölcsö- 
nös kizárást, ami szükséges feltétele annak, hogy az erőforrások konzisztens 
állapotban maradjanak. A probléma megoldására az egyes platformokon 
(Windows, Linux stb.) más-más eszközök léteznek. A lényegük azonban min- 
den esetben az, hogy azon kódrészek elején, melyek a védett erőforráshoz fér- 
nek hozzá, zárat kell létrehozni (például az erőforráshoz tartozó megfelelő 
mutex, szemafor stb. objektumon), a kód lefutását követően pedig fel kell ol- 
dani a zárolást. A fenti kódrészletben a MyTemplate osztálysablon DoSafe- 
Operation tagfüggvénye fér hozzá védett erőforráshoz, így ennek törzsében 
levő műveletekre vonatkozóan kell megoldani a zárolást. Ha ezt elvégezzük, 
akkor a DoSafeOperation több szálból is biztonságosan használható. A leg- 
egyszerűbb megoldás az lenne, ha a DoSafeOperation első sorában minden 
esetben zárolást alkalmaznánk, a tagfüggvényből való kilépéskor pedig felol- 
danánk. Ennek azonban van egy hátránya: amennyiben egy adott esetben 
előre tudjuk, hogy a MyTemplate osztálysablont egyszálú környezetben al- 
kalmazzunk, akkor a zárolás indokolatlanul lassítja a DosSafeOperation mű- 
velet végrehajtását (a zárolás alkalmazása általában időben költséges műve- 
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11. fejezet: Cs sablonok 

leteket jelent). A MyTemplate osztálysablon arra mutat példát, hogyan lehet 
egy osztályt a szálbiztonság szempontjából paraméterezhetővé tenni sablon. 
technikákkal úgy, hogy egyszálú és többszálú környezetekben is a lehető leg. 
hatékonyabban alkalmazható legyen. A MyTemplate osztálysablon egy sablon. 
paraméterrel rendelkezik (ThreadingMode)), ezzel lehet megadni az alkalma. 
zandó zárolást. Ha nincs szükség zárolásra, a SingleThreadedModel osztályt 
adjuk meg paraméterként. Ez esetben a DoSafeOperation első sorában a 


zárobjektum NoLock osztálybeli objektum lesz. Ezt könnyen ellenőrizhetjük: a 
SingleThreadedModel osztályban a Lock egy typedef-fel definiált, beágyazott tí. 
pus, mégpedig a NoLock. A fenti sor esetében lefut a NoLock konstruktora, amely 
szándékosan üres, így nem végez zárolást. Sőt, nemcsak hogy nem végez zárolást, 
hanem a fordítás során alkalmazott optimalizáció következtében bele sem fordul 
a kódba, így olyan, mintha a fenti sort le sem írtuk volna. A példa jól szemlélteti, 
hogy a sablonok alkalmazásával rendkívül hatékony kód készíthető. 

Most ellenőrizzük azt az esetet, amikor a MyTemplate osztálysablont több- 
szálú környezetben kívánjuk felhasználni. Mindössze egy dolgunk van: az osz- 
tálysablont a MultiThreadedModel osztállyal paraméterezzük fel. Ez esetben a 
DoSafeOperation első sorában a 


guard objektum egy ObjectLock osztálybeli objektum lesz (hiszen a Multi- 
ThreadedModel osztályban a Lock egy typedef az ObjectLock-ra), ennek konst- 
ruktora pedig megfelelően végrehajtja a zárolást. A DoSafeOperation függ- 
vényből való kilépéskor a guard objektum (lokális változó!) felszabadul, ga- 
rantáltan meghívódik a destruktora, a destruktor pedig oldja a zárolást. Az 
erőforrások felszabadítására gyakran alkalmazott technika a destruktor ilye- 
tén módon való alkalmazása, ez ugyanis minden körülmények között — kivé- 
telek esetében is — biztosítja a lokális erőforrás felszabadítását. 
Nem esett még szó arról, miért kell megadni a 


/ typename Threadingiodel:tLőck guárd(thisjz ETET 


sor elején a typename kulcsszót. A typename jelzés a fordító számára, hogy ami 
utána zet Át egy típus. Enélkül a fordító azt is feltételezhetné, hogy a 
ThreadingModel::Lock a ThreadingModel statikus tagfüggvénye. A példában a 
guard lokális változó, ez esetben a typename kulcsszó használata nem kötelező. 
Ha a guard tagváltozó lenne (a fenti kifejezéssel), akkor a typename alkalmazása 
kötelező lenne. 

Az itt bemutatott összetettebb példa egy olyan tervezési irányelv alkalma- 
zását illusztrálja, melynek lényege, hogy az osztályok viselkedésének különböző 
aspektusait (esetünkben egy ilyen volt, az alkalmazandó zárolási technika) ho- 
gyan lehet megfelelő osztálysablont használó technikákkal megoldani. 





11.2. Osztálysablonók 
Statikus sablon tagváltozók 


A sablonosztályoknak is lehetnek statikus tagváltozóik és Salt 
junk egy olyan számlálót megvalósító osztálysablont, tél eárésésá dő 
értékét: 


nem objektumonként) tartja nyilván a számláló 








A statikus tagváltozók definíció szerint az adott osztályhoz és nem annak ob- 


K 13 
j i 7 . Az osztálysablonokra vonatkozóan a statikus tagvál- 
jektumaihoz tartoznak. osztály: ztákat e tal vegán 


tozók az egyes sablonkifejtésekhez (param: er. Kö 
toznak. Ez a példánk esetében azt jelenti, hogy külön counter KKEL 
tartozik a Countercint2 és a Countercshortz paxaínátan babak srélBr Ete 
Sőt, amennyiben osztálysablon-specializációt alkalmazunk, a s: 


zók az egyes specializációk esetében is külön értéket vehetnek fel. 
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11. fejezet: Cst sablonok 





Sablonokat támogató nyelvi konstrukciók 


Sablonok esetén egyaránt lehetőség van beépített és általunk definiált típusok 
(osztály, struktúra) sablonparaméterként való megadására. Természetes elvá. 
rás, hogy a sablonok írásakor ezeket egységesen tudjuk kezelni. A Ct- nyely 
ezért lehetőséget biztosít rá, hogy mind a beépített típusú, mind az adott osz- 
tálybeli, illetve struktúra típusú változókat azonos szintaktikával a típusuknak 
megfelelő kezdőértékre inicializáljunk. Nézzünk egy példát az int típus esetére: 





Míg az első sorban az i változó értéke nem definiált, a második sorban a j vál- 
tozót az int típus alapértelmezett értékére, vagyis nullára inicializáljuk. Te. 
kintsünk most egy függvénysablon példát: 





A példánkban x garantáltan inicializálva lesz. Ha T egész típus, akkor 0-val, 
ha pedig egy saját típus, akkor annak alapértelmezett konstruktorával. 








TIZENKETTEDIK FEJEZET 


Bevezetés a Ct-t szabványos 1 
sablonkönyvtárába 


Ennek a fejezetnek a témája jelentősen eltér az eddigiek többségétől. Koráb- 
ban ugyanis főként a Ctt nyelvi elemeit igyekeztünk bemutatni az egyes 
nyelvi konstrukciók szintaktikájával és használatával együtt. Ebben a feje- 
zetben nem jelennek meg új kulcsszavak, tulajdonképpen C-t nyelven megírt 
osztályokat mutatunk be. 

Egy strukturált környezetben — például a C nyelv esetében — természete- 
sek az olyan elvárások, hogy rendelkezésre álljanak különböző általános célú 
függvények, mint a printf, az fopen, és még sorolhatnánk. Ha egy strukturált 
szemléletű nyelvhez szabványos függvénykönyvtár jár, akkor az objektumorien- 
tált nyelv esetén szabványos osztálykönyvtárra számíthatunk. 

A C-4 nyelv esetén ez a Szabványos Ct-4 könyvtár (Ctt Standard 
Library) amely sajnos valamivel később követte a nyelv megjelenését." Ezt 
többek között általános célú osztályok alkotják, ilyen például a kivételosztály, 
amiről a 10.2.2. részben volt szó. A szabványos Ct-4 könyvtár osztályai és 
függvényei mind az std névtérben érhetők el. A könyvtár a C-ben megszokott 
függvényeket is tartalmazza. 

A Szabványos C-t-4 könyvtár egy részhalmaza a Szabványos Ct-t sab- 
lonkönyvtár (Standard Template Library, STL). Az STL kihasználja a Ctt 
sablonjai által kínált lehetőségeket, és ezek segítségével meglehetősen bonyo- 
lult típusokat hoz létre. Ezek az osztályok nagyon rugalmasan konfigurálha- 
tók, illetve példányosíthatók. Szerteágazóságuk miatt könyvünk keretei kö- 
zött csak a leggyakrabban alkalmazott koncepciók és funkciók bemutatására 
van lehetőség, speciális testreszabás vagy egyéb különleges igény esetén ja- 
vasoljuk a [3](9] irodalmak tanulmányozását vagy az egyes STL-implementá- 
ciók weboldalait. 

Az STL három fő részre osztható: 


s  [/0 könyvtár 
s  Tárolók 


9. Algoritmusok 





7 Ezért számos régebbi fejlesztésű platform nem vagy csak eléggé kezdetleges formában 
támogatja ezeket az osztályokat. Az újabb fejlesztésű nyelveknek (Java, Cít) nagy elő- 
nyük, hogy a nyelvet együtt tervezték az osztálykönyvtárral, és már megjelenésük idő- 
pontjában egységes szemlélet hatotta át őket. 














12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 


Az első kategóriába az adatbevitelt és beolvasást biztosító osztályok tartoz- 
nak, ezeknek az alapjait az 5. A C-t 1/0 alapjai fejezetben tárgyaltuk. A tá- 
rolók általános célú osztályokat valósítanak meg, mint a dinamikus tömb, a 
halmaz, az asszociatív tömb és a sztring. Az algoritmusok általános célú mű- 
veleteket támogatnak, például rendezés, keresés, összehasonlítás, bejárás. 

A C4-4 STL fő fejlesztési szempontja a gyorsaság és a futásidejű haté- 
konyság volt. A programozói interfészt is ezeknek az alapelveknek vetették 
alá a tervezők, ami első látásra kissé elrettentő lehet. Ugyanakkor, ha meg- 
szokjuk a néha meglepően hosszú hibaüzeneteket, amelyek többszörösen 
egymásba ágyazott sablonosztályokról szólnak, gyors, hatékony és hordozható 
eszközhöz jutunk, amellyel sok munkát takaríthatunk meg. A megszokáshoz 
vezető utat számos példával és a szemlélet kialakulásához vezető általános 
elvek bemutatásával szeretnénk könnyebbé tenni. 

Az STL része a Ct-- szabványnak, amely főként az interfészt definiálja, a 
konkrét megvalósításban az egyes implementációknak szabad kezük van. 
A főbb STL-implementációk az alábbiak: 


s SGI (Silicon Graphics, www.sgi.com): szabadon letölthető 
s — Dinkumware (http://www.dinkumware.com): fizetős 


e GNU Standard Ct- Library (http://gcec.gnu.orgílibstde---)): a gce/gt-t 
fordító része 


s Apache Ctt Standard Library (http:/incubator.apache.org/stdexx): 
szabadon letölthető 


Ebben a fejezetben természetesen nem vállalkozhatunk az STL legapróbb 
részleteinek bemutatására. Először rövid ízelítőt adunk az STL funkcionali- 
tásából. Utána részletezzük a fontosabb tárolókat és a tárolókhoz kapcsolódó 
hatékonysági megfontolásokat, majd rátérünk az algoritmusokra. Végül a 
sztringkezelést és a magyar nyelvű fejlesztést vesszük sorra. A fejezet kidol- 
gozásánál főként a [3][4] [9] [10] irodalmakra támaszkodtunk. 


12.1. Alapkoncepciók 


Ebben a fejezetben példákon keresztül lépésről lépésre megi ü 

STL alapfogalmaival. Az itt bemutatott koncepciók álapjás KEzTő Bizkoröre 
mozóvá válhatunk: élni tudunk az STL egyszerűbb felhasználási lehetőségeivel. 
Amennyiben az STL-t közepes bonyolultságú feladatok (például pointereket 
tartalmazó tárolók) megoldására is alkalmazni akarjuk, a további, az STL 
egyes részeit mélyebben ismertető fejezetek áttanulmányozását is javasoljuk. 
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12.1. Alapkoncepciók 
TETTEK az.-— 


12.1.1. Tárolók 


Eddigi példáink többsége tárolóelemeket valósított meg, amivel jól lehetett il- 
lusztrálni a Ct-t egyes nyelvi elemeit, hiszen az osztály, illetve annak funkcio- 
nalitása magától értetődő volt, nem kellett hosszú utat bejárnunk a feladat 
megfogalmazása és a megoldás osztályokra bontása között. A gyakorlatban vi- 
szont ritkán írunk tárolóosztályokat, hiszen azokat — mivel mindenkinek szük- 
sége lehet rájuk — az STL-ben megírták helyettünk. Ugyanakkor az eddigi pél- 
dák segítenek, hogy megértsük az egyes megoldások mögött rejlő megfontolá- 
sokat, így a felhasználás is logikusabb és könnyebben megjegyezhető lesz. 
A leggyakrabban a következő tárolóelemeket használjuk: 





vector dinamikus tömb 








set halmaz 
list kétszeresen láncolt lista 
map asszociatív tömb 





Ezeknek a tárolóknak az alapvető használatát a további fejezetek mutatják 
be. Előtte viszont az STL egyik legfontosabb alapgondolatának bevezetéséhez 
tekintsünk egy nagyon egyszerű feladatot! 


Feladat: Számoljuk meg, hány "h karakter található egy C stílusú sztringben! 


Ehhez be kell járnunk egy karaktertömböt. A megoldásban egy pointert veze- 
tünk végig a tömb egyes elemein. Azt is mondhatjuk, hogy végigiterálunk a 
tömbön, vagyis minden elemét sorra véve bejárjuk. Ezzel összhangban a vé- 
gigvezetett pointert iterátornak neveztük el. 





A sztring esetén könnyen meghatározhatjuk, meddig kell mennie a for ciklus- 
nak, hiszen a sztring végét "0" karakter jelzi. Egy int tömb esetén ilyenre nincs 
lehetőség, ott az indexelést szoktuk használni. Míg a fenti, sztringes feladat 
megoldása gyakori, álljon itt egy kevésbé gyakran alkalmazott és — valljuk be — 
tömbök esetén nem is túl kényelmes megoldás egy int tömbre. 
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12. fejezet: Bevezetés a Cst szabványos sablonkönyvtárába 


Feladat: Számoljuk meg, hányszor fordul elő a 42 egy egészeket tartalmazó tömbben! 





A fenti megoldás nagyon hasonlít az előző, sztringes példához egy kivétellel; a 
tömb végét egy másik mutatóval jelezzük. Érdemes megfigyelnünk, hogy a 
tömb végét jelző mutató tulajdonképpen érvénytelen: a tömb utolsó eleme 
után mutat. Ezért például a tpend kifejezést használni súlyos hiba. 

Összegezzük a fenti megoldások közös vonásait! 

s Az első elemre mutató pointer adott volt. 

s — Létrehoztunk egy pointert, amely a tömb végét jelentette. 

e — Létrehoztunk egy pointert, amely bejárja a tömböt. 


s — A pointerek típusa természetesen függött a tárolt adattípustól. 


A fenti megfontolásokat általánosíthatjuk, így eljutunk az STL absztrakt tá- 
roló legfontosabb alapkoncepcióihoz. 


Dinamikus tömb 


Vizsgáljuk meg az alábbi példát, amely az STL által biztosított dinamikus 
tömb felhasználására mutat példát! 











Jól látható, hogy az STL — akárcsak a szabványos C-t [/0 — az std névtérben 
található. Szükségünk van még egy include direktívára: a beépítendő állo- 
mány neve megegyezik a tároló nevével, amely jelen esetben vector. A szab- 
ványos tárolók az std névtérben találhatók. A vector formális paramétere a 
tárolandó elem típusa. Jelen esetben egy int típusú elemekből álló dinamikus 
tömböt hozunk létre. 

A vektornak két fontos mérőszáma van. Az egyik a méret (size), a másik a 
kapacitás (capacity). Ha visszagondolunk a 3.5. Dinamikus adattagot tartal- 
mazó osztályok fejezet FIFO példájára, láthatjuk, hogy nem hatékony, ha egy 
tároló minden egyes alkalommal, amikor beszúrunk egy elemet, egy elemmel 
nagyobb helyet foglal, és átmásolja oda addigi tartalmát és az új elemet. Ehe- 
lyett célszerű nagyobb területet foglalni, mint az elemek aktuális száma. Ezt 
nevezzük a vektor kapacitásának. A tároló mérete a tárolóban található ele- 
mek száma. Az elsőt a capacity tagfüggvény adja vissza, a másodikat a size. 

Amíg a tároló mérete kisebb, mint a kapacitása, nem foglal új memóriate- 
rületet, vagyis ez az , üzemmód" nagyon hatékony. Ha a tároló mérete megha- 
ladja a kapacitást, akkor újra kell foglalnia a memóriaterületet."9 A kapacitás 
megadása nélkül a tároló az első elem beszúrásakor implementációfüggően 
viselkedik: vagy túl sok memóriát foglal, vagy egyáltalán nem. A kapacitást a 
reserve függvénnyel állíthatjuk be. Fontos, hogy a vector esetén nem csök- 
kenthető a kapacitás: ha a reserve függvény argumentuma kisebb az aktuális 
kapacitásnál, akkor a függvény nem változtat a tároló állapotán." 

Ezek után a vector push. back tagfüggvényét használhatjuk, ha a tömb 
végéhez szeretnénk hozzáfűzni egy elemet. 

Itt jegyezzük meg, hogy a hozzáadott elem lemásolódik. Ez része az STL 
alapfilozófiájának: ha egy tárolóba beteszünk egy elemet, másolat készül róla, 
és az kerül bele a tárolóba. Ezek szerint számítanunk kell arra, hogy itt meg- 
hívódik a másolókonstruktor. 





79. Ilyenkor a legtöbb vektorimplementáció megduplázza a vektor addigi kapacitását. . 

"0 Ha mégis csökkenteni szeretnénk a tároló kapacitását, másoljuk át tartalmát egy másik vek- 
torba, amelynek a csökkentetett kapacitást állítottuk be. Létezik egy másik megoldás [10]: 
vectorcinto(int Vector). swap(int Vector); § 
Ilyenkor a másolókonstruktort hívjuk meg konverziós értelemben (lásd 8.2.1. Konverzió 
független típusok között fejezet), amely létrehozza az intVector másolatát, amely már op- 
tímális kapacitással jön létre, majd ennek az ideiglenes másolatnak hívjuk meg a swap 
függvényét, amely hatékonyan megeseréli a két vektor belsejét, vagyis az ideiglenes vek- 
tor átmásolódik az intVectorba, az eredeti intVector az ideiglenes objektumba, majd fel- 
szabadul az ideiglenes objektum. 
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yos sablonkönyvtárába 





12. fejezet: Bevezetés a Crt szabván! 


özek után kiíratjuk a tömb tartalmát. Az STL tárolókat iterátorokkal járhat. 
ese ömb iterátorai nagyon hasonlítanak az előző fejezet példáinál használt 
juk be. A kisert den egyes tárolótípusra létezik egy iterátortípus is, Így az int 
KSzAmKüSS la ök vektorra is. Ez a típus a vectorcint2:iterator, A tároló első 
elemet tés ff srálort a begin, a tároló utolsó eleme után mutató iterátort az 
ézstt áj stk É fija vissza. Az iterátorok nagyon hasonlítanak az előző fejezet. 
cs dlzajmutátója, de nem minden tároló esetében értelmezett a pointe. 
teknő stukszokott összes művelet (tt——, egész szám hozzá dás: 
szehasonlítás). A dereferencia operátor u) természetesen mindig rendelkez sre 
áll. Vektorok esetében mindegyik, a pointereknél megs zokott műveletet használ: 
hatjuk. Mindezek fényében érthetővé válik a tömb elemeit kiírató ciklus. 8 

Hangsúlyozzuk, hogy a vectorSint2 osztály end() tagfüggvénye szintén egy 
vectorcint2:riterator típusú iterátorral tér vissza, ugyanakkor ez nem az utol- 
só elemre mutató iterátor, hanem az utolsó elem után mutató iterátor! En- 
nek következtében a visszatérési értékére nem alkalmazhatjuk a " operátort! 
Például a cout cc tintVector.end) kifejezés teljesen hibás. 

Ha a tömb elejére szeretnénk beszúrni egy elemet, akkor a vectornak azt az 
insert tagfüggvényét kell hívnunk, amely egy iterátort és egy beszúrandó elemet 
vár. A tagfüggvény a megadott iterátorral jelzett elem elé szúrja be az új elemet. 





dása, kivonása, ösz- 











// Beszúrunk egy 0-t a tömb elejére: 
intvector. insert(intvector begin) 02; 


Ha meg akarunk változtatni egy elemet, akkor a dereferencia operátort kell 
alkalmaznunk az iterátorra. 


.  "intvector.beginO s 2; álni 


A fenti sor megváltoztatja az első elemet. Természetesen ez nemcsak az első 
elemmel, hanem bármelyik elemmel történhet, amelyre lekérdeztük a rá mu- 
tató iterátort. 

Ha törölni szeretnénk egy elemet a tömbből, ezt többféle módon is megte- 
hetjük. Ha az utolsó elemet akarjuk kitörölni, akkor a pop. back() tagfügg 
vény használható. A pop. back() tagfüggvény nem tér vissza a kivett elemmel, 
ezt annak hívása előtt a back() tagfüggvénnyel tudjuk lekérdezni. Ha egy tet- 
szőleges elem kitörlése a célunk, az erase() tagfüggvényt használjuk, amely a 
törlendő elemre mutató iterátort várja paraméterül. Az összes elem törlésére 
a clear() függvény használható. 

Természetesen egy tömbtől elvárjuk, hogy indexelve is kiírhassuk a tartal: 
mát, illetve lekérdezhessük a méretét. Az elem értékét indexelve is megváltoz- 
tathatjuk. Ha az indexelés operátort használjuk, oda kell figyelnünk, ugyanis a 
tároló nem ellenőrzi, érvényes-e az átadott index. Ha azt szeretnénk, hogy a tár 
roló érvénytelen index esetén kivételt dobjon, az indexelés operátor helyett 


18 ÖN 3 B s zat Elébb 
foszási at tagfüggvényt. Az alábbi programrészlet a szokásos módon járj 
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———— S I! NAL Hlöpköncepeiők 





Ha egy adott pozíciójú elemet szeretnénk törölni a vektorból, az erase tag- 
függvényt használjuk, amelynek egyik változata egy iterátorral megadott 
elemet töröl, és a következő érvényes pozícióval tér vissza. A visszatérés itt 
különösen fontos, hiszen ha törlünk egy elemet, akkor annak az iterátora ér- 
vénytelenné válik. Így ha végig szeretnénk iterálni egy vektoron, és törlünk 
néhány, bizonyos feltételeknek megfelelő elemet, akkor a törlés után a vissza- 
térési értéket használhatjuk fel az iteráció folytatására: 


// Törlünk minden elemet, melynek értéke 1 
for(vectorcint; : : 


iterator it - intvVector.beginO;it !- intvector.end() ;) 


Li 
if(rit sz 1) 
it - intvector.erase(it); 
else 
4tit; 
Hi 


Ha töröltük az elemet, akkor az erase visszatérési értéke a következő elem, 
egyébként pedig a szokásos léptetés, amit ezúttal az esetszétválasztás miatt 
nem írtunk a ciklus fe; be. Felmerülhet a kísértés, hogy a fenti kódrészlet 
helyett az alábbi, futási hibát eredményező ciklust írjuk, ám ez hibás: 





for(vectorcints::iterator it - intvector.beginO; 
it !z intVector.endO ;trit) 


1 
íf("rit sz 1) 
intvector.erase(it); 


ú; // Az it iterátor érvénytelenné válik: hiba 


Itt ugyanis az it iterátor az erase tagfüggvény hívása után érvénytelenné vá- 
lik, hiszen az elem nem létezik többé. Így a ciklusfej kiértékelése során az 
it44 kifejezés érvénytelen művelet, amely futási hibát eredményez. 





Kétszeresen láncolt lista 


Jóllehet megismerkedtünk a dinamikus tömb használatával, az iterátorok 
igazi előnyeit még mindig nem mutattuk be. Ehhez ismerkedjünk meg a két- 
szeresen láncolt lista (list) STL osztállyal! 
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yos sablonkönyvtárába 





12. fejezet: Bevezetés a Ctt szabván! 


ginclude dist: 
$include ciostream: 


using namespace std; 

ínt mainO 

( 
Tistcints intList; 
// A Vista végére beszúrunk egy elemet. 
intList.push.back(1); 


// Még egy elem 
intList.push.back(2) ; 


// kiíratjuk a lista tartalmát 
for(listcints::iterator it - intList.beginO; 
it !- intList.endO;trit) 


1 
coutectit; //12 
8 
d 


Láthatjuk, hogy szinte alig van kü önbség a vektort, illetve a láncolt listát 
használó program között. Mivel a láncolt listára nem értelmezett az indexelés 
operátor, ezért az STL megalkotóinak olyan koncepciót kellett kitalálniuk, 
amely mind a dinamikus tömbre, mind a listákra, mind egyéb tárolókra is 
használhatók. Ez a közös koncepció az iterátor. A listánál használatos iterá- 
tor valamivel kevesebbet tud, mint a vektor által visszaadott, mert a listaite- 
rátorhoz nem adhatunk hozzá egész számot. Ez nem meglepő, hiszen míg a 
tömbnél ez a művelet természetes, a listánál egyenesen szokatlan. 
Használatbeli különbségek is akadnak: közismert, hogy a listába sokkal 
egyszerűbb beszúrni egy elemet, mint a tömbbe, hiszen nem kell az utána kö- 
vetkező elemeket eggyel odébb csúsztatni, illetve új folytonos területet foglalni. 
Ezért a lista esetében nem különböztetünk meg kapacit. illetve méretet. 


A listából a vektornál bemutatott módon (lásd előző fejezet) tudunk ele- 
meket törölni. 





Halmaz 


EZT HK olyan tárolókkal foglalkoztunk, amelyekben az elemek a 
Tó. SÉol a ús al EK zSSáÉTl sorrendben tárolódtak. Vannak olyan táro- 
trák EE uOKK OB] 482 tároló dönti el, mert a tároló felhasználójának egészen 
ben például Hp beseza , mint a vektorok és a listák esetében. A halmaz eseté 
vagy nincs, Százátdés HESS tadül, hogy egy elem benne van-e a halmazban 
maz a halmaz. lé énk beszúrni elemeket, viszont ha egy elemet már tartal: 
zömbös, hogy a ha eedje, hogy még egyszer beletegyük. Az teljes" kö: 
mértékben a ÍRÉRTSZOS milyen sorrendben tárolja az elemeket, így ezt teljes 
ilyenkor a beszú ÁEELEZGEB minket a műveletek gyorsasága érdekel. A tároló 

úrandó elem értéke szerint határozza meg az elem pozícióját, 
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hogy az elvárt műveletek minél hatékonyabbak legyenek. A halmazok esetén 
eza reprezentáció valamilyen bináris fa [19]. Mivel az elem helyét egy bináris 
fában annak értéke határozza meg, nem írhatjuk elő a pozícióját. 

Azokat a tárolókat, amelyeknél a sorrendet a tároló felhasználója hatá- 
rozza meg, szekvenciális tárolóknak (seguence containers) nevezzük, míg 
ahol a sorrendet tárolóba berakott elem értéke határozza meg, asszociatív 
tárolóknak (associative containers) hívjuk. 

Az asszociatív tárolóknak szükségük van valamilyen rendezési elvre, 
amelyet szigorú gyenge rendezésnek (strict weak ordering) hívunk. Ez 
alapértelmezésben a c operátor túlterhelését írja elő a tárolandó elemek típu- 
sára az alábbi feltételek betartásával: 


, ha ax igaz, akkor y3x ne legyen igaz (antiszimmetria), 
e ha xy és cz, akkor x£z (tranzitivitás), 


e — xáx sohase legyen igaz (irreflexivitás). 


A fenti összefüggéseket érdemes ellenőrizni a túlterhelt c operátorra, ha nem 
szeretnénk furcsa működést. Ugyanakkor, ha objektumorientált gondolko- 
dásmódot követve alakítunk ki egy rendezési szempontot, jóval nehezebb 
megsérteni a fenti szabályokat, mint betartani. Ha a tárolandó elemek ren- 
delkeznek c operátorral, a tároló két lépésben végzi az összehasonlítást: 


e — Ha e1ce2 igaz, akkor megvan a sorrend. 


. — Ha e2Zei igaz, akkor is megvan a sorrend, ha nem, akkor e2—e1. 


Összefoglalásként elmondhatjuk, hogy alapértelmezésben az asszociatív táro- 
lókban tárolt elemeknek rendelkezniük kell értelmesen túlterhelt c operátor- 
ral.§: Később látni fogjuk, hogy ezt a műveletet másképpen is megadhatjuk, 
de a szigorú gyenge rendezés feltételeinek akkor is teljesülniük kell a műve- 
letre. Az adott implementáció ezt ellenőrizheti nyomkövető üzemmódban. 
Ezek szerint az STL-ben kétféleképpen is ellenőrizhetjük, hogy két elem 
megegyezik-e. Az egyik módszer a C operátorral megadott szigorú gyenge 
rendezési feltételből származtatható a fenti módon, a másik a hagyományos, 
-— operátort használó összehasonlítással. Az első esetben a két elemet ekvi- 
valensnek nevezzük, és ekvivalenciáról (eguivalence) beszélünk, a másik 
esetben a két elem egyenlő, és egyenlőségnek (eguality) nevezzük a vizsgált 
tulajdonságot. Az ekvivalenciát akkor használjuk, amikor rendezett elemek- 
kel dolgozunk, mint például az elemeiket rendezetten tároló halmazok eseté- 
ben, Ha rendezetlen elemekkel dolgozunk, például rendezetlen vektorban ke- 
resünk egy értéket, akkor az egyenlőséget használjuk az egyezés eldöntésére. 





" Újabb programozási nyelvek ilyen helyzetben egy adott int. 
elő (Comparable, IComparable), amely teljes rendezést biztosít a ( 
hasonlóan, 


erfész implementálását írják 
stremp függvényéhez 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 


Nézzünk egy példát a halmaz használatára, részletes magyarázata a kód. 
részlet után következik: 


$finclude cset; 
$include ciostream: 


using namespace std; 
int main O 
setcints intSet; 


// Mivel a halmazban minden elem csak egyszer szerepelhet, 
// nem számít a pozíció. sú 
intSet.insert(2); 

intSet.insert(3); 


// Ha ismerni akarjuk a beszúrt elemre mutató iterátort, 
// az insertO) visszatérési típusa egy pár: 
paircsetcint:: :iterator ,bool5 p; 


// Ha kétszer akarunk beszúrni egy elemet, a második paraméter 
// hamis. A második elem a 3-ra mutató iterátor, 
pz-intSet.insert(3) ; 


coutcc"p.first; // Az iterátor által mutatott érték: 3 
coutccp.second; // A bool változó tartalma: 0 


for(setcints::iterator it - intSet.beginO); 
7 it !- intSet.endO) ;rrit) 


coutcctit; // 23 


.  // A halmazban kereshetünk is: egy iterátort kapunk vissza 
nen az elemre §7-ül 

. Setcint:s::iterator it-intset.find(2); 
jot TE ThtSEn HON VÉMt 








. — // kiíratjuk a t elemet: 


A beszúráshoz szokás szerint az insert 
rési értékét akár el is dobhatjuk: ha az 
függvény semmit sem csinál, 
melyik eset valósult meg, akkor szükséi 


tagfüggvényt használhatjuk. A visszaté- 
elem már szerepel a halmazban, akkor a 
, ellenkező esetben belerakja. Ha szeretnénk tudni, 
1 z IVO günk van a paii ű STL osztályra. 
A pair egy értékpárt tárol, és deklarációjának egy véselétá 87 alábbi: EL 
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A pair sablonparaméterei az első, illetve a második adattag típusai. Jól látha- 
tó, hogy az elsőre a first tagváltozóval, a másodikra a second tagváltozóval hi- 
vatkozhatunk. A párnak van egy alapértelmezett konstruktora, amely a first, 
illetve second tagváltozókat a típusuk alapértelmezett konstruktorával inicia- 
Jizálja, illetve megadhatunk kezdeti értéket a pár kétparaméterű konstrukto- 
rában. A kódrészlet idézése nélkül megemlítjük, hogy a pair osztálynak van 
másolókonstruktora is. A pár segédosztály sok helyen előbukkan, ahol érték- 
párokat kell tárolni (például asszociatív tömbök, hasítótáblák stb.), vagy ahol 
- mint esetünkben is — két értékkel tér vissza a függvény. A pair a utility ál- 
lományban található. 
A halmazosztály insert tagfüggvénye két értéket szeretne visszaadni: 


e  abetett elemre mutató iterátort: ha már benne volt, akkor arra; 


e egy bool értéket, hogy az elemet sikerült-e beletenni a halmazba, vagy 
már benne volt. 


Ezt a két értéket kapjuk vissza a példakódban is: az első paraméter az iterá- 
tor típusa, a második bool. Md Hé 

A bejárás hasonló az eddigiekhez: az iterátor koncepciója itt is működik. 
Ennél viszont nem módosíthatjuk az elemeket az iterátorokon keresztül, mi- 
vel a visszaadott iterátor konstans. Ez logikus, hiszen az asszociatív tárolók 
esetén az érték határozza meg a pozíciót, és annak megváltozásával az elemet 
is át kellene helyezni, Így a tároló ezt nem támogatja, a tároló felhasználójá- 
nak kell törölnie a régi elemet, és beszúrni az újat. ta 

Az asszociatív tárolók a rendezettség miatt gyors keresést tesznek lehető. 
Vé. A halmaz esetében megadjuk az elemet a /ind tagfüggvény paramétere- 
ként, és ha benne van a halmazban, akkor a rá mutató iterátorral, ha nem, 
akkor az end() iterátorral tér vissza. 
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12. fejezet: Bevezetés a Ctt szabványos 


Asszociatív tömb ; j A 
Bizonyos értelemben az asszociatív tömb a dinamikus e általánosítása, 
Míg a tömbben pozitív egész számokat adhatunk ús a semi zárójelben, 
itt bármelyik rendezhető típust használhatjuk, amely rende! ezik a szigorú 
des 3 nogató c operátorral. Az azonosításra használt értékeket 
em indexnek, hanem kulcsnak nevezzük. 
filozófus születési évét tartja nyilván. 


gyenge rendezést tám 
asszociatív tömbök esetén n 
Az alábbi program néhány 


az 


$include cmap: 
$include cstring: 
$include ciostream 
using namespace std; 


int main ÖO 


; // Az elso a kulcs típusa, a másik a tárolt elemek típusa 


mapcstring, int: philos; 


// Beszúrjuk az értékeket: 
philos("Kant"] - 1724; 

philos("Heidegger"] - 1889; 
philos("Nietzsche"] 1844; 


// keresés 
mapcstring,ints::iterator cur - philos.find("Kant"); 


// Ha az utolsó elem után mutató iterátor, akkor nem találta. 
if(cur!-philos.end()) 
1 
// A visszatérés egy pár: első a kulcs, második a tárolt érték 
cout cg (tcur).first; // Kant 
3 cout cc (tcur).second; // 1724 


// Ez nem lesz benne 
cur - philos.find("Platon") ; 


[/ Ha az utolsó elem után mutató iterátor, akkor nem találta. 
4 szék oS eat) 


cout cc "Not found." cc endi; 
// Végigiterálunk az asszocia ömbö 
r tív tömbön 
for(mapcstring, ints::iterator it - philos.beginO; it !- ; 
: philos.endO;tti0) 
// A visszatérés egy pár: első a kulcs, második a tárolt érték 


cout cc (tit).fi rstccend1; 
T3 cout cc (sit) secondccendi; 
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12.1. Alapkoncepciók 
Az asszociatív tömböket a map STL osztály valósítja meg. Az első sablonpa- 
raméter a kulcs, a második a tárolandó érték. Esetünkben a kulcs egy beépí- 
tett, STL string osztály, amelyet részletesen a 12.5. Szövegkezelés fejezetben 
mutatunk be. Látható, hogy ugyanúgy az indexelés operátort használjuk az 


asszociatív tömbök esetében is, mint ahogy a hagyományos tömböknél tettük. 
Az operátor az alábbi módon működik. 


e Megkeresi, hogy az adott elem benne van-e a tárolóban. Ha benne 
van, visszaad egy referenciát az értékre. 


s Ha nincs benne, létrehoz egy alapértelmezett konstruktorral iniciali- 
zált értéket, és arra ad vissza referenciát. 


Vagyis az STL asszociatív tömb esetén nem lehet , túlindexelni": ha a hivat- 
kozott elem nem létezik, akkor létrehozza. Ez egyben hibalehetőséget is rejt 
magában. A 


[ coutaecphilosí"Nietsche"]; // Helyesen: Nietzsche, egy z kimaradt 


sor létrehoz egy új elemet "Nietsche" kulccsal, és nullát rendel hozzá, amit ki is 
ír, holott valószínűleg nem ezt szerettük volna, csak elírtuk a nevet. Az indexe- 
lés operátor helyett használhatjuk az insert tagfüggvényt, amely egy párt vár: 


7 philos.insert(paircsstring, ints("Hege1",1770)); 


Létezik a pár létrehozásának egyszerűbb módja is, amely a make pair STL 
sablonfüggvényt használja. Az implicit példányosítás miatt (lásd 11.1. Függ- 
vénysablonok fejezet) a típust nem kell megadnunk. Sőt, ugyanezen okból ki- 
folyólag a típuskonverzió nagy részét fordítási időben letudhatjuk. 


. philos.insert(make pair("Hegel1",1770)) ; 


Ezzel tulajdonképpen csak az alapértelmezett konstruktor inicializálásának 
idejét takaríthatjuk meg az indexes jelöléssel szemben, amely viszont jóval 
kényelmesebb. Az insert tagfüggvény visszatérési értékéből azonban megtud- 
hatjuk, hogy benne volt-e az a kulcs a tárolóban, amit bele akarunk tenni: a 
módszer teljesen megegyezik a halmazoknál bemutatott visszatérési értékkel 
(lásd előző fejezet). 

a Ha meg akarunk keresni egy kulcsot a tárolóban, és nem akarjuk, hogy, a 
tároló automatikusan létrehozza, ha nincs benne, akkor a find tagfüggvényt 
használjuk. Ez a függvény szintén nagyon hasonlít a halmazéra, a különbség 
csak annyi, hogy az iterátor egy párra mutat, ha sikeres volt a keresés. A pár 
első tagja a kulcs, a második a hozzá tartozó érték. Ez minden map-beli 
iterátorra igaz. Jól látható, hogy a szokásos iterátoron keresztüli bejárás s0- 
rán is párral kell dolgoznunk. 
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Természetesen a kulcsot nem változtathatjuk, hiszen az jelöli ki az elem 
helyét a belső adatreprezentációban (valamilyen bináris fában), de az értéket 
igen. Példaként tegyük át igazságtalanul Kant születését egy évvel későbbre 
kétféle módon: 


// Indexelés operátorral AgIY 
philos("kant"] - 1725; 


// Iterátorokkal § 
mapcstring,intz::iterator cur z phílos.find("Kant"); 
íf(cur !z philos.end()) // Ha megtalálta 

(Ctcur) second z 1725; 


Ami a sorrendet illeti, érdemes megfigyelni, hogy a Kant adatait valósághűen 
kezelő, eredeti program az alábbi sorrendben írja ki a filozófusokat, amikor 


bejárja az egész tömböt: 


Hegel 


IYZŐ VS ZEZTÉTSE fal 


Heidegger 
1889 
kant 

1724 
Nietzsche 
1844 


V 


Jól lehet látni, hogy a kulcs szerinti rendezés az STL string osztály esetén ka- 
rakterenként ábécé szerinti rendezést jelent, és teljesen független a beszúrás 
sorrendjétől. Továbbá, mivel a tároló a kulcs szerint van rendezve, arra a 
kérdésre, hogy mikor született Nietzsche, gyors választ kapunk, ahhoz vi- 
szont, hogy megtudjuk, ki született 1844-ben, be kell járnunk az egész tárolót, 
és legrosszabb esetben — ahogy a fenti példában is —, utolsóként találjuk meg. 


12.1.2. Iterátorok 


A tárolók megismerése közben láttuk, hogy a pointerek szerencsés általánosí- 
tásával, az iterátorokkal hasonlóan kezelhetjük a legkülönfélébb tárolókat. 
Ugyanakkor az egyes tárolótípusoknál különbségek is adódtak; a tárolók által 
visszaadott iterátorokra különböző műveletek voltak értelmezettek, attól füg- 
gően, hogy milyen tároló adta vissza őket, A dinamikus tömb esetén hozzáad- 
hattunk egy egész számot az iterátorhoz, a láncolt lista ezt érthető okokból 
nem támogatta, A tárgyalást és az $TL dokumentálását megkönnyítendő az 
iterátorokat csoportokra oszthatjuk aszerint, hogy milyen műveletek értelme- 
zettek rajtuk. Így egy tároló leírása esetén sokkal egyszerűbb ezekre a kate- 


góriákra hivatkozni, mint minden egyes alkal, ; ő 
3 tő 
műveleteket. Ezek az iterátorkategóriák az TESB felsorolni az elvégezheti 
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S e..LLLC-[CVvV Ö VE VS V/ö/ Getz zráéatóőa 


beviteli iterátorok (input iterators) 

, kimeneti iterátorok (output iterators) 

s  előreléptető iterátorok (forward iterators) 

. kétirányú iterátorok (bidirectional iterators) 


. véletlen hozzáférésű iterátorok (random access iterators) 


A továbbiakban ismertetjük az egyes iterátorkategóriákhoz kapcsolódó műve- 
leteket, miközben az iterátorok számos új alkalmazását is bemutatjuk. 


Beviteli iterátorok 


A beviteli iterátorok onnan kapták a nevüket, hogy tipikusan a beviteli adatfo- 
lyamhoz rendelhetünk ilyen iterátort. Mivel az istream osztály is része az STL- 
nek, támogatja az iterátoros hozzáférést. Az adatfolyamokhoz hozzárendelt iterá- 
torokat adatfolyam-iterátoroknak (stream iterators) nevezzük. Az alábbi prog- 
ram egy példát mutat a beviteliadatfolyam-iterátorokra (istream iterators). 


$include ciostreamz 
$finclude citerator: 
using namespace std; 


int main O 


í 
istream iteratorcchar: eofStreamIterator; 


forCistream iteratorcchar: chariterator(cin); 
chariIterator!zeofStreamIterator; 
44charIterator) 


5. 


coutcc "charIterator; 
J 
J 


A bementiadatfolyam-iterátorokat az istream. iterator osztály zárja egységbe, 
amely az iterator állomány beépítését teszi szükségessé. Ez az osztály iterátor 
alaposztályból származik, és az egyes iterátorműveleteket leképezi az istream 
osztály tagfüggvényeire, jellemzően a 22 operátorra. Azokat az osztályokat, 
amelyek valamely iterátor alaposztályból származnak, és az iterátorművele- 
teket egy másik osztály műveleteihez illesztik, iterátoradaptereknek (iterator 
adapters) nevezzük. ; 
Az istream iterator osztályt kétféleképpen lehet létrehozni. Ha az alapér- 
telmezett konstruktorral hívjuk, akkor az adatfolyam végét jelző iterátorhoz ju- 
tunk, Ez analóg a tárolók end tagfüggvénye által visszaadott iterátorral. 
A bemenetiadatfolyam-iterátor akkor válik ilyenné, ha vége van az adatfolyam- 
nak, vagy valami hiba történt. Ha egy istream típusú objektumot adunk át a 
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konstruktorban, akkor az iterátor ehhez a beviteli adatfolyamhoz lesz hozzá. 
rendelve. Vagyis a bejárás nagyon hasonlít a tárolókhoz, csak a begin, illetve az 
end tagfüggvény helyett kell más megoldást alkalmaznunk. Az iterátor a már 
jól ismert 52 operátort használja az olvasáshoz, ezért a megszokott módon mű- 
ködik. A fenti program addig olvas a bemenetről, amíg állományvége karakter 
nem érkezik (Windows alatt CtrlZ, Unix-Linux alatt Ctrl-4-D). Az 55 operátor. 
nál megszokott módon a bejárás csak új sor bevitele esetén kezdődik el. Nem 
kizárt, ugyanakkor nem is valószínű, hogy a szabványos bemenetet fogjuk 
iterátorokkal olvasni. Állományok esetén viszont hasznosnak bizonyulhat: em- 
lékeztetünk rá, hogy az ifstream osztály (lásd 5.3. Állománykezelés fejezet) az 
istream leszármazottja, vagyis a fenti módszer állományokra is érvényes, 
ifstream típusú objektumot is átadhatunk az istream. iterator konstruktorában. 

A fenti példákban elég kellemetlen, hogy a 22 operátor , lenyel" bizonyos 
karaktereket. Ha a bevitelt bájtonként szeretnénk végezni, hatékonyabb az 
adatfolyambuffer iterátoradaptere, az istreambuf iterator. Ennek használatát 
az alábbi kódrészlet mutatja be: 


ifstream filestream("c:Wadat.txt"); 
istreambuf. iteratorcchar: eofStreamIterator; 








r5 chariterator(fileStream) ; 
erator !- eofStreamIterator; 


A beviteliadatfolyam-iterátor és a beviteli adatfolyambuffer iterátoradaptere 
beviteli iterátorok. A beviteli iterátorokra az alábbi műveleteket értelmezzük: 

e — dereferencia operátor (?): csak olvasható 

s 5 operátor: csak olvasható tag 

e — prefix és postfix t-t 

s — összehasonlítás (—, !-— 

s — másolókonstruktor 
Megjegyezzük, hogy ha a visszaté; 


során, a prefix t-t hatékonyabb, 
kell tárolni az előző értéket. A 


rési értéket nem használjuk fel a léptetés 
mint a postfix, hiszen az utóbbi esetében el 


ze egy beviteli iterátort, lehet, hogy az 
ú atok ki Z et olvasnak be. A fenti tulajdonságok szin- 
te mindegyike jól megjegyezhető, ha arra zokdólátk kögyóa spevikli 
EZER jellemzően beviteli adatfolyamon dolgoznak, VAGVA csak olyan mű- 
eleteket engedhetnek meg, amely elvégezhető a beviteli adatfolyamokon. 
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12.1. Alapkoncepciók 
Kimeneti iterátorok 
A kimeneti iterátorok a beviteli iterátorok analógiájára onnan kapták a ne- 
üket, hogy jellemző alkalmazási területük a kimeneti adatfolyam. Az alábbi 
vüke m illusztrálja a kimenetiadatfolyam-iterátorok használatát.52 





Az ostream iterator iterátoradapter is kétféleképpen hozható létre. Az első 
esetben a konstruktor egy ostream típusú objektumot vár, ilyenkor az értékek 
egymást követően íródnak ki. Második lehetőségként megadhatunk egy 
elválasztószekvenciát (példánkban ez az új sor), ilyenkor az egyes kiírt érté- 
kek közé ez a szekvencia kerül. Esetünkben az A és a B karakter után sor- 
emelés következik. Mivel az ostream. iterator a c£ operátorral ír a kimenetre, 
nem kell léptetést végeznünk, ezért a ttoutStream nem csinál semmit. Ugyan- 
akkor az iterátorkategória megköveteli, hogy a tt művelet értelmezve legyen. 

A kimenetiadatfolyam-iterátor kimeneti iterátor. A kimeneti iterátorokon 
az alábbi műveleteket értelmezzük: 


e  dereferencia operátor ("): csak írható 

s prefix és postfix tt 

s — másolókonstruktor 
A kimeneti iterátorokra érdemes úgy gondolnunk, mintha , fekete lyukba" ír- 
nánk. Nem tudjuk ellenőrizni, helyes volt-e az írás vagy sem, nem tudjuk le- 


kérdezni a kiírt értéket, nem tudjuk összehasonlítani a kimeneti iterátorokat, 
és nem tudjuk az adatfolyam végét. 


See ME ds 
ki Természetesen a kimeneti adatfolyambuffernek is létezik iterátoradaptere, az ostream- 
buf. iterator, amely szintén kimeneti iterátor. 
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Előreléptető iterátorok 

Az előreléptető iterátorok egy szekvenciát képesek bejárni csak az elejétől a 
vége felé haladó lépésekben, de ezt többször is. Az általuk mutatott elem le- 
het megváltoztatható, illetve megváltoztathatatlan. Bizonyos értelemben a 
beviteli és a kimeneti operátorok kombinációjának tekinthetők. Mivel az elő- 
reléptető iterátor egy szekvencia egyirányú bejárására szolgál, a szekvencia 
végét ellenőrizni kell. Ez a kimeneti iterátorok esetén nem lehetséges, az elő- 
reléptető iterátoroknál viszont kötelező. Míg sem a kimeneti, sem a beviteli 
íterátorok esetén nem lehet újra bejárni a régi iterátorpozíciókat, az előrelép- 
tető iterátor képes rá. Ennek legfontosabb következménye, hogy ha lemáso- 
lunk egy előreléptető iterátort, az iterátor és másolata egymástól függetlenül 
ugyanazon a szekvencián fog végigiterálni. Ez sem a beviteli, sem a kimeneti 
iterátorok esetén nem így működött. 

Míg az előző két kategória esetén könnyű volt tipikus példát mutatni, 
ahol az adott iterátorral tudtunk bejárni egy STL adatstruktúrát, az előrelép- 
tető iterátoroknál ez nem egyszerű. Az SGI STL egyszeresen láncolt listája 
ilyen iterátort ad vissza, ez a tároló viszont jelenleg nem része a Ctt szab- 
ványnak. Ugyanakkor számos algoritmusnak elég egy irányban bejárni egy 
szekvenciát. Ezek az algorítmusok előreléptető iterátort írnak elő bemenetük- 
ként, hiszen beérik az előreléptető iterátorok által garantált műveletekkel. 

Az előreléptető iterátorokon elvégezhető műveletek az alábbiak: 


s dereferencia operátor (7) 

. — -2 operátor 

e — prefix és postfix 44 

s — összehasonlítás (—, 1-) 

s — alapértelmezett konstruktor 
s — másolókonstruktor 


s  - operátor 
Kétirányú iterátorok 


A kétirányú iterátor az előrelé i á i é é 
át : ptető iterátor finomítása a visszaléptetés tá- 
mogatásával, Az új funkciót az alábbi operátorokkal vehetjük igénybe: 


9 — prefix és postfix — — 


A prefix, illetve a postfix — — ai rátor ki 
operátoroknál említettünk: FlneKéset 
náljuk a prefix változatot. 


Az alábbi tárolók kétirányú iterátorokat támogatnak: list, set, map. 


Bi álasztására ugyanaz igaz, amit a tt 
ha nincs szükségünk a visszatérési értékre, hasz: 





12.1. Alapkoncepciók 
ZEKE KUKKTK KE EKETEKEKEEKzz meszi 


véletlen hozzáférésű iterátorok 


A véletlen hozzáférésű iterátorok a kétirányú iterátorok által támogatott mű- 
veleteken kívül tetszőleges nagyságú ugrásokat tesznek lehetővé mindkét 
irányban, vagyis nemcsak egyenként lépkedhetünk. A véletlen hozzáférésű 
iterátor lényegében minden C-ben megszokott pointerműveletet támogat. Az 
eddig megismert tárolók közül a dinamikus tömb ad vissza véletlen hozzáfé- 
résű iterátort. A kétirányú iterátorok műveleteit a véletlen hozzáférésű iterá- 
torok az alábbi műveletek támogatásával egészítik ki: 


e — [] operátor: a megadott indexű elemel tér vissza 
e 7 és--operátorok: a megadott eltolással léptetik az iterátort 


e  Kétargumentumú tt, - operátorok (egyik argumentum egész): a meg- 
adott lépésnyire utána lévő vagy megelőző elem. Mindkét sorrendben 
működik egészre: 3-tit, illetve itt-3. 


e — Kétargumentumú - operátor (mindkettő iterátor): megadja, hogy a két 
iterátor hány lépésnyi távolságra van egymástól. 


e — Összehasonlítás (c 2,c- 57) operátorok: az iterátorok pozícióját ha- 
sonlítják össze, a kisebb indexű iterátorpozíció a kisebb. 


Láthatjuk, hogy a véletlen hozzáférésű iterátorok ugyanúgy használhatók, 
mint a C pointerek az egydimenziós tömbökön. 


Iterátoradapterek 


Az iterátoradapterek közül az eddigiek során az adatfolyam iterátorokat is- 
mertük meg. Megállapíthatjuk, hogy az iterátoradapterek olyan építőelemek, 
amelyek egy iterátorokat eredetileg nem támogató adatstruktúrát iterátoro- 
kon keresztül is hozzáférhetővé tesznek. Ebben a fejezetben két további iterá- 
toradaptert mutatunk be. Ezek az alábbiak: 


s  fordítóiterátorok (reverse iterators) 


e — beszúró iterátorok (insert iterators) 


Elsőként a fordítóiterátorokat vesszük sorra. A fordítóiterátorok becsomagol- 
ják az eredeti iterátorokat, és megváltoztatják a bejárás irányát. 

hee EZAZ ÁJÓ A első dése eMlzé dl] sa zó e adeéz zi ése Et sze ő 
Feladat: Térjünk vissza a filozófusokhoz, és töltsünk fel a nevükkel egy vektort! Írassuk ki a 
nevüket a betéttel sorrendjében, illetve fordított sorrendben! 


A megoldást a fordítóiterátorok teszik igazán egyszerűvé. A tárolók ugyanis 
nemcsak az őket eredeti sorrend szerint bejáró iterátorokat támogatják, ha- 


nem a fordítóiterátorokat is. A megoldást az alábbi kódrészlet mutatja: 
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12. fejezet: Bevezetés a Ctt szabványos sablonkönyvtárába 
finclude ciostream: űgy 


$include cvector: 
using namespace std; 


ant main Ö 
( 
vectorcconst chart:5 names; 


names .push.back ("Heidegger") ; 
names .push. back ("Kant") ; 
names . push. back("Nietzsche") ; 


for(vectorcconst chart5::iterator 
it - names.beginO;it !- names.endO ;4rit) 


23 


cout cz tit cz endi; 


J 


for(vectorcconst char"; ::reverse, iterator 
it -n ames.rbeginO; it!- names.rend();ttit) 
í 


cout cc tit cc endl; 
s 
3 


A program kimenete az alábbi: 


Heidegger 
Kant 
Nietzsche 
Nietzsche 
Kant 
Heidegger 


A vector osztály a már jól ismert begin, illetve end tagfüggvényekhez hasonló- 
ls Stb bocsát. két, fordítóiterátorral visszatérő függvényt: az 
ELIK. AzEléteet ú rbegin az utolsó elemre mutató iterátort adja vissza, 
deteléétazik KÖZE k 4 mutatót. Az rend iterátorra nem alkalmazhatjuk a 
ben az utolsó elemtől hi EE Ht operátor a példában látható módon a tömb- 
fin látálletsésssza alad az első felé. Hasonlóan viselkedik a kétargumen- 
léptetik a — — és a .— Fizösznásós A fordítóiterátorokat ezekkel ellenkező irányba 
az irányt követi, F. ázó rátorok, valamint a kétargumentumú - operátor is ezt 

, "ordítóiterátorokkal tehát igen egyszerű fordított irányban 


iterátorok eseté a 

iterátorok igs Ha Sz EZÉ ÉETS felcserélését végzik, hiszen a kétirányú 

iterátoroknál az aritmetikai a többi műveletet, míg a véletlen hozzáférésű 

rátort a fordítóiterátor k. szavaleteket is felcserélik. Iterátorból fordítóite- 
" konstruktorával hozhatunk létre, fordítóiterátorból 
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iterátort a fordítóiterátor base tagfüggvényével. A fordítóiterátor az rend() ál- 
tal visszaadott iterátorának a begin() által visszaadott első iterátor elé kelle- 
ne mutatnia. Ilyen pozíció viszont nincs a tárolókban. Ezért a fordítóiterátor 
belső iterátora ekkor fizikailag az első iterátorra mutat, logikailag pedig az 
első elem előtti pozíciót adja vissza. Vagyis a fordítóiterátorok által vissza- 
adott pozíciók az iterátorokhoz képest eggyel el vannak tolódva balra. A lé- 
nyeg: egy pozíció konvertálása során számítsunk arra, hogy a fordítóiterátor 
által mutatott pozíció a konvertált iterátor előtti pozíció, illetve visszakonver- 
tálásnál a fordítóiterátor pozíciója utáni pozíció. A filozófusok esetén ez a kö- 
vetkezőképpen jelenik meg: 


vectorcconst char"5::iterator pos -names.beginO; 
44pOS; 

cout cs tpos; // Kant 

vectorcconst char"; ::reverse. iterator rpos(pos); 
cout cc trpos; // Heidegger 

vectorcconst chart5::iterator rrposz rpos.baseO ; 
cout cc tpos; // Kant 


A beszúróiterátorok, röviden beszúrók (inserters) olyan iterátoradapterek, 
amelyek a kimeneti iterátor kategóriájába tartoznak. Ezek az iterátorok az 
értékadásnál nem az éppen mutatott elemet írják felül, hanem beszúrják az 
értékül adott elemet egy meghatározott pozícióba. A pozíciótól függően három 
beszúróiterátor-típust különböztetünk meg: 


s előre beszúró (front inserter) 
s hátra beszúró (back inserter) 


s általános beszúró (general inserter) 
A beszúrók működését az alábbi példával illusztráljuk: 


vectorcconst char": names; 

names . push. back ("Hegel"); 

insert iteratorcvectorcconst chart:2 
insertíterator (names , names .begin ) ; 


"insertiteratortr-"Heidegger"; 
tínsertiterator44z"Kant" ; 
"insertiteratorrrz-"Nietzsche"; 


A fenti példában a beszúróiterátor beszúrja a három filozófust a megadott sor- 
rendben Hegel elé. Az általános beszúró először a tároló típusát várja sablonpa- 
raméterként, majd a pozíciót, ahova be kell szúrnia az elemet. Asszociatív táro- 
lók esetén ez a pozíció csak ajánlás, a tároló nem feltétlenül a megadott helyre 
fogja beszúrni az elemet, hanem az értékét figyelembe véve helyezi el. 
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12. fejezet: Bevezetés a Ctt szabványos sablonkönyvtárába 


A példában általános beszúró szerepel, az insert, iteratoron kívül használhat. 
juk a front. insert. iterator (előre beszúró), back. insert. iterator (hátra beszúró) be. 
szúrókat. Ezek létrehozásakor természetesen nem kell pozíciót megadnunk. 

A beszúrók az alábbi alapelven működnek: a dereferencia operátor magával 
a beszúróiterátorral tér vissza. Így a beszúróiterátor — operátora hívódik meg, 
amely a beszúró típusától függően meghívja a tároló push. back, push front 
vagy insert tagfüggvényét. Természetesen, ha a tárolók nem támogatják vala. 
melyik függvényt, a hozzá tartozó beszúró nem használható. Az eddigi tárolók 
közül az előre beszúrók csak a listával működnek, a hátra beszúrók csak lis. 
tákkal és vektorokkal. 

Mivel a fenti módszerrel elég hosszadalmas a beszúrók létrehozása, az 
STL kényelmi funkciókat is rendelkezésre bocsát, amelyek a make pair függ- 
vényhez hasonlóan kihasználják a függvényekre alkalmazható implicit pél- 
dányosítást. Ezek az alábbiak: 


e front inserterítároló) 
e back inserterítároló) 


e — inserterítároló, pozíció) 


A fenti három segédfüggvény használata nagyon hasonló. Az alábbiakban a 
back inserterre mutatunk egy példát: 


back. inserter (names) -"Heidegger" ; 
back inserter(names)-"Kant" ; 
. back inserter(names)-"Nietzsche"; 


Az eddigiek alapján a beszúrók csak eggyel több módszert jelentenek az ele- 
mek beszúrására, akár tagfüggvényeket is használhatnánk helyettük. Az iga- 


zi szerepük azonban az, hogy nagyban leegyszerűsítik az egyes algoritmusok 
használatát. 


Tartományok 


A tartomány (range) két iterátorral határolt elemek balról zárt, jobbról nyílt 
kek Az intervallumok jelentőségét egyrészről az adja, hogy a táro- 
Az. Egé. izét tudnak kezelni egy intervallumot, mint ha egyen- 
végző teta és me elemeket. Az elemenkénti beszúráson kívül beszúrást 
side batákok TES mindegyike támogatja tartomány beszúrását is, an 
ERGLESA faetádk; tartomány elemenkénti beszúrásánál. A szabvány elő. 
elemek rögtö. pesánn zi szúrunk be, akkor az eredetileg is a tárolóban lévő 

gtön a végleges pozíciójukba legyenek átmozgatva.53 











12.1. Alapkoncepciók 
(Lem segg n ÜLNÉNK Ü üt KÜ ÉKEK sza 


Ez például a vektorba történő beszúrás esetén egyetlen nagy elmozgatást 
jelent, szemben az egyenkénti beszúrás számos mozgatásával. A másik fő érv 
a tartományok mellett az, hogy az algoritmusok nagy része intervallumokon 
végez művelet. 





Feladat: Másoljuk át egy vektor tartalmát listába, majd írassuk ki a lista tartalmát! 





A megoldást az alábbi kódrészlet mutatja: 


vectorcconst char": namesvector; 

// Feltöltés 

namesvector.push. back("Hegel"); 
namesvector . push. back("Heidegger") ; 
namesvector . push. back("Kant") ; 
namesvector . push. back("Nietzsche") ; 


// Másolás 
Tistcconst char"2 namesList; 
namesList.insert(namesList.beginO , namesvector.beginO) , 
namesvector.end()); 

// kiíratás 
for(Ilistsconst char7:::iterator 

ít - namestist.beginO;it !- namesList.end();rit) 
t 


coutcstitccendi; 


J 


A beszúrásnál az első paraméter azt adja meg, hogy a listán belül hova szúr- 
juk be a tartományt, a másik két paraméter a tartomány elejét és végét jelzi. 
Érdemes észrevennün k, hogy a lista insert tagfüggvénye feltételezi a megfele- 
lő iterátorkategóriát és a tárolt típust, de arról semmit sem tud, hogy az ite- 
rátorok egy vektor elemein iterálnak végig. Ezért az iterátorokkal megadott 
tartományok nagyon rugalmas felületet kínálnak. 

Vizsgáljuk most meg az átadott tartomány érvényességét! A vektor begin 
tagfüggvénye az első elemre mutató iterátort adja vissza, amelyet egészen a 
vektor végéig léptethetünk, Az end függvény által visszaadott iterátor viszont 
érvénytelen, hiszen az utolsó elem után mutat! Mivel a tartományok gyakran 
tárolók elemeit jelentik, a megadott tartományok első elemét beleértjük a tar- 
tományba, az utolsó iterátor által mutatott elemet nem! Ezen megfontolás 
miatt tekintjük az iterátorok által kijelölt intervallumot balról zártnak, jobbról 
nyíltnak. Ha nem egy egész tárolót akarunk átadni tartományként, hanem csak 
egy ét, akkor ez a szemlélet kissé kényelmetlen lehet, sőt, hibák forrá 1 
válhat, Ilyen esetben ne felejtsük el az átadásnál megnövelni az iterátort: 


















Vectorcconst charso::iterator kantíterator snamesvector.beginOr2; 
dás e 


. NamesList,insert(namesList.begin() , namesvector begin , 
8 kantrteratorr1); 
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Ha a fenti kódrészletben elhagyjuk a t1-et, Kant-ú6m lesz benne a listában, 
hiába mutat rá a kantlterator, hiszen az utolsó IALÁTOSI nem értjük bele a 
tartományba. A vektor esetén hozzáadunk egyet kihasználva a véletlen hoz- 
záférésű iterátort, más iterátortípusoknál a kk operátort alkalmazhatjuk. 

A fenti kódrészletet tovább optimalizálhatjuk, a lista . eredeti tartalmára 
ugyanis nincs szükségünk, és ilyenkor célszerű az assign tagfüggvényt használni: 


namesList.assign(namesvector . beginO , kantiterators1) ; state 


Mivel a lista eredetileg üres volt, ennél is hatékonyabban járunk el, ha azzal 
a konstruktorral hozzuk létre a listát, amely egy tartomány alapján iniciali. 


zálja a tárolót. Érdemes fejben tartani, hogy minden szabványos tárolónak 
van ilyen konstruktora. 


Jisteconst charts nameslist(namesvector.beginŐ ,kantiteratorsij; "7 


Fontos, hogy a tartományban szereplő iterátoroknak érvényeseknek kell lenniük, 
és ezt mindig annak kell ellenőriznie, aki megadja a tartományt reprezentáló 
iterátort, és nem annak, aki paraméterként kapja. Egy tároló esetén általában 
annyit kell ellenőriznünk, hogy az elsőként megadott iterátor kisebb-e, mint a 
második. Ez véletlen hozzáférésű iterátorok esetében nem probléma, hiszen 
összehasonlíthatjuk őket. Egyéb iterátorok esetén a 12.1.3. Algoritmusok feje- 
zetben tárgyalt keresőalgoritmusokat használhatjuk az iterátorok által muta- 
tott értékek megkeresésére, és tárolón belüli pozíciójuk összehasonlítására. 
Általában az iterátortartomány iterátorait nem változtatjuk, csak az álta- 
luk kijelölt elemeket. Ezért nem okozunk különösebb félreértést, ha az iterá- 
tortartományokon végzett műveletekről beszélünk: ilyenkor mindig az adott 
iterátortartomány által kijelölt elemeken végzett műveleteket értjük. 


12.1.3. Algoritmusok 


Az algoritmusok iterátorok által kijelölt tartományokon végeznek művelete- 
ket. Ez azt jelenti, hogy az algoritmusok előírják a megkapott iterátorok ka: 
tegői és az előírt kategória által rendelkezésre bocsátott iterátorművele- 
teken kívül semmilyen feltételezéssel nem élnek. Ez nagyon nagy rugalmas- 
ságot tesz lehetővé: az algoritmusok minden olyan adatstruktúrán képesek 
műveletet végezni, amely közvetlenül vagy iterátoradaptereken keresztül 
támogatja az iterátorokat, valamint a programozónak elég az iterátortarto- 


mány (lásd előző fejezet) alapkoncepcióját ismerni ahhoz, hogy kijelölje az0- 
kat az adatokat, amelyeken futtatni 


Ahogy az algoritmusok elői 





szeretné az algoritmust. s 
A X nyei, úgy a hátrányai is az absztrakcióból e! 
vvső ÉKZZTÉZENTEB csak az iterátorokon keresztüli hozzáférést használják, 
feledés e rüneétk tárolók belső szerkezetét nem tudják kihasználni egy adott 
TÁNLINÉK MG a vagy leegyszerűsítésére. Például, ha egy keresői 
ödik vektorok és listák által visszaadott iterátorokra, nem lehet har 
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tékony halmazokra és asszociatív tömbökre is, hiszen a belső felépítés haté- 
konyan kereshető adatstruktúráihoz nem fér hozzá iterátorokon keresztül. 
Így a halmazok és az asszociatív tömbök keresőalgoritmusait megvalósító tag- 
függvények jóval gyorsabbak, mint az általánosabb, kizárólag iterátorokat 
használó keresőalgoritmusok. 

A továbbiakban kiindulásként bemutatunk néhány egyszerű algoritmust 
majd rátérünk arra, hogy miként adhatjuk át az algoritmusoknak a Baját 
magunk által megírt műveleteket, és végül megmutatjuk, hogyan lehet egy 
vektort rendezetten tartani néhány algoritmus segítségével. A következő feje- 
zetek példái feltételeznek egy egészekkel feltöltött vektor objektumot: 


$include ciostream: 
$include cvector: 

$include calgoríthm: 
using namespace std; 


int main Ö 

( 
vectorcintz numbers; 
typedef vectorcints::iterator numbers iterator; 
numbers. iterator positon; 


numbers .push. back(2) ; 
numbers .push. back(3) ; 
numbers .push. back(4) ; 
numbers . push. back(1) ; 


for(numbers íterator ítzs numbers.begin) ;it!-numbers.end() ;rrit) 
( 
coutcctit; 
§ 
h 


A fenti kódrészletbe beépítettük az algorithm állományt, amely az algoritmu- 
sok használatához szükséges, valamint deklaráltunk egy position nevű iterá- 
tort, amely egyelőre nem mutat sehova. 





Néhány egyszerűbb algoritmus 


Elsőként keressük meg a fenti vektor legnagyobb és legkisebb elemét! Ezt a 
min element, illetve a max element algoritmusokkal tehetjük meg: 


7/  Minimumkeresés 
Position-min. element (numbers .begín() , numbers .end() ; 
coutactposítion; // 1 


7/  Maximumkeresés 


Positionzmax. element (numbers . begin) , numbers .endO ) ; 
COutcctposition; //4 
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Ismét felhívjuk a figyelmet arra, hogy a tartományokba az első iterátor álta] 
mutatott elem beleértendő, de az utolsó iterátor által mut atott elem nem. 
A fenti algoritmusok nem módosítják a tároló tartalmát. Az ilyen algoritmu. 
knak (nonmodifying algorithms) nevezzük, 


sokat nem módosító algoritmuso ú Kézi é 7 
Ezek után keressük meg a 4-et a számok között! Ezt a find algoritmus 


támogatja. 
posi tion-find(numbers . begin , numbers. end() , 49; Vf 


k 
if(position!-numbers.endO) 
Cat ZEMMEGYEN: SESÁ ÉT // Megvan: 4 


else 
coute"Nincs meg"; 


A find vagy visszatér az első olyan tárolóbeli értékre mutató iterátorral, amely 
megegyezik a megadott elemmel, vagy a tartományt kijelölő utolsó iterátor- 
ral, esetünkben a tároló vége után mutató iterátorral, amelyet az algoritmus 
egyezőség szempontjából már nem vizsgál. Így a visszaadott értéket össze kell 
hasonlítanunk az end() által visszaadott iterátorral, hogy lássuk, sikeres volt-e 
a keresés. 

Igen gyakori művelet a másolás. Ezt a copy algoritmussal tudjuk elvégezni, 
amelynek a deklarációja az alábbi: 


templatecclass InputIterator, class Outputiterator: 
Outputíterator copy( 
Inputiterator First, // a másolandó tartomány eleje 
Inputiterator Last, // a másolandó tartomány vége 
sz Outputiterator DestBeg // a céltartomány eleje 
3; 


Jól látható, hogy a bemeneti tartományt két beviteli iterátor jelöli ki, a céltar- 
tományt pedig egy kimeneti iterátor. A céltartományt elég csak egy iterátor- 
ral megadnunk, hiszen a bemeneti tartományból kikövetkeztethető a mérete. 
Ez általánosan jellemző tulajdonsága az STL algoritmusoknak. 

Ha visszaemlékezünk a kimeneti iterátorral szemben támasztott köve: 
telményekre, tudjuk, hogy csak írni és léptetni lehet. Ha úgy másolunk a cél- 
tartományba, mondjuk, egy másik vektorba, hogy írunk és léptetünk, akkor 
felülírjuk az elemeket. Ráadásul gondoskodnunk kell róla, hogy legyen hely a 
céltartományban, az algoritmusok ugyanis sohasem ellenőrzik a megadott 
tartományokat. Ez így elég körülményes megoldás lenne. Az előző részben 
ugyanakkor bevezettük a beszúróiterátorokat, amelyek pontosan erre a hely: 
tárt aeákte ek Amikor ugyanis a beszúróknak értéket adunk, azok ? 
rolóba. Í ke eszúrófüggvényét felhasználva beszúrják az elemeket a té 

: "gy már egyszerűen átmásolhatjuk a vektor tartalmát. 
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ES ETTE e ao lee höz adta 
e See TWERT TET TKRTEZZE ETET ET ZT VÉT TE SE TT Nee 
Útmutató: Jóllehet a copy algoritmust nagyon egyszerű használni, sokszor 

nyabb megoldás. Miután a beviteli iterátorokkal nem lehet eldönteni a betérek ésdtölsán has Ba) 
etét, a kimeneti iterátorokat pedíg csak léptetni és írni lehet, a copy algoritmus egyenként szúrj 
be az adatokat. Mint ahogy a 12.1.2. fejezet Tartományok részében láttuk, jóval hatékonyabb új 


— a tartományt váró konstruktort hívni, ha most hozzuk létre a céltárolót 
— az assign tagfüggvényt használni, ha a céltároló régi tartalmára nincs szükségünk, 


— a tartományt váró insert tagfüggvényt használni. 


Arra eddig még nem mutattunk gyakorlatilag is hasznos példá ié 
tunk : példát, hogy miért 
jó, ha az adatfolyamokhoz is iterátorokat rendelünk. Mivel a copy fizgöbt ás 
célját egy kimeneti iterátor jelöli ki, ez akár egy ostream iterator is lehet. Az 
alábbi kódrészlet kiírja a fenti numbers2 vektort szóközzel elválasztva: A 





Nyilvánvaló, hogy a copy algoritmus a céltartományt módosítja. Az ilyen al- 
goritmusokat módosító algoritmusoknak (modifying algorithms) nevezzük. 


Műveletek mint algoritmusargumentumok 


Könnyen előfordulhat, hogy nemcsak egy adott értéket szeretnénk megkeresi 
egy tárolóban, hanem valamilyen feltételt kielégítő elemet, például az első pá- 
ratlan számot. A find algoritmusnak létezik egy hasznos változata, a find if, 
amelynek szintén három paramétere van: ; a 





s Inputilterator, class Predicates 
findcif( ZET et 






Ebből az első kettő megegyezik a find algoritmuséval, vagyis kijelölik a kere- 
MZTÉSTETTBK a harmadik pedig egy függvényt vár, amelynek visszatérési 
feljésk l, és akkor igaz, ha az adott elem kielégíti a kívánt feltételt, amely 

5 esetében páratlan szám. A függvény paramétere megegyezik az ite- 
rátorok által mutatott típussal, jelen esetben int-tel, int-eket tartalmazó vek- 


torról lévén szó. Így először írunk egy olyan függvényt, amely eldönti, hogy 
égy egész szám páros-e. 
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12. fejezet: Bevezetés a Ctt szabványos sablonkönyvtárába 


araméterként átadott függvényeket, amelyek visszaté. 
kátumoknak (predicate) nevezzük. Vagyis a find if al. 
goritmus utolsó paramétere predikátum, és az algoritmus SIy ate elemeket ke: 
res a megadott tartományban, amelyekre a FIGULÁB igaz értékkel tér visz. 
sza. A find if függvény visszatérési értéke megegyezik a find algoritmuséval: 
az első olyan elemre mutató iterátor, amely eleget tesz a keresési feltételek. 


nek, vagy a tartomány végét jelölő iterátor. 


on z fi nd. if(numbers . begin ,numbers .end() , is. odd) ; 


Azokat az algoritmusp! 
rési értéke bool, predi 





positi 
átion 1- numbers.endO) : 7 
isi ca "Found: " cc tposition; // Megvan: 3 ké keni 
else e) 
cout cc "Not found."; kéevő; 


Az algoritmus egy lehetséges implementációja egyszerű: 


for G First 1- Last; ttFirst) 
if (PredCFirst)) 
break; 
return (First); 





Jól látható, hogy az algoritmus a predikátum után zárójelbe teszi az aktuális 
elemet, amely a példánk esetében egy függvényhívást jelent, méghozzá az 
is odd függvényét. A Ctt sablonok behelyettesítő természetéből következik, 
hogy minden olyan adatstruktúrát átadhatunk a predikátum helyén, amely 
után leírhatjuk zárójelben az aktuális elemet, és nem ad szintaktikai hibát, 
valamint egy if szerkezetben nem hibás a visszatérési értéke. Vagyis elkövet- 
hetjük azt a perverziót, hogy olyan objektumot adunk át, amelyben túlterhel- 
tük a ( ) operátort! 







num)íreturn num$2 1- 0;) 





EL ÖBEN ogre gat ; 
(numbers .begin() , numbers .end() , isodd) ; 
h. 1.0 példában ezzel az égvilágon semmit sem nyertünk, ráadásul többet is 
; Ez gépelnünk. Ha azonban nem ilyen egyszerű a feladatunk, mint elddti 
éti számról, hogy páratlan-e, hanem meg kell jegyeznünk egyes 
e. ajé ; or Jets elegánsabb megoldás, mint statikus változók haszná: 
ET KÜ en. Azokat az algoritmusparaméterként átadott osztályo- 

bje yek túlterhelik a 0 operátort, függvényobjektumoknak (function 
object) vagy funktoroknak5: (functor) nevezzük. 
ek EMÉSZT A 


5 A funktor kifej. il ; 
jllssés zi öss a matematika már az STL előtt lefoglalta teljesen más jelentésben, 
iakban a függvényobjektum szót használjuk. 
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sales [EGE MÖRSKOMTENYK TÓK, 


kissé összetettebb példához a for. each algoritmust használjuk. Ez az 
algoritmus többek között a tárolókat bejáró, meglehetősen hosszú for ciklusok- 
tól szeretné megkímélni az STL programozót. A for each deklarációja az alábbi: 


. templatecclass Inputiterator, class Functions 
s; for.each( 
Inputíterator First, 
ator Last, 


. Function Func 
pi 


Az algoritmus bejárja a megadott tartományt, meghívja az utolsó paraméter- 
ként megadott függvényt vagy függvényobjektumot, és a megadott függvény- 
pointerrel vagy függvényobjektummal tér vissza. Implementációja például az 
alábbi lehet: 


for G chkFírst !- ChkLast; 4rChkFirst) 
.Func("chkFirst); 
return (FuncC); 


Számoljuk ki a numbers vektor tagjainak négyzetösszegét a for each algorit- 
mus felhasználásával! 

Mivel a négyzetösszeg kiszámolásához emlékeznünk kell a részösszegekre, 
függvényobjektumot használunk. Egy lehetséges függvényobjektum az alábbi: 


class sguare. sum 


unsigned sum; 
public: 
sguare. sumO) : sum(0) í) 
void operator) (int num)fsum az numtnum;) 
unsigned get. sum íreturn sum;) 


Mivel a for each nem használja a () operátor visszatérési értékét, ezért azt 
ezúttal void-nak deklaráltuk. Ezek után lefuttatjuk a for. each algoritmust, és 
a visszaadott függvényobjektumból kiírjuk a négyzetösszeget. 


Sguare sum ss - 
sz for. each(numbers . begin() , numbers . end() , sguare. sumO ) ; 
Cout cc ss.get. sum; // 30 


A függvényobjektumot a konstruktor konverziós működésével hozzuk létre an- 
nak alapértelmezett konstruktorán keresztül (lásd 8.2.1. Konverzió független tí- 
Pusok között fejezet). Jól látható, hogy amikor a bejárás során meg kell jegyez- 
tis értékeket a számoláshoz, ahogy példánkban el kellett tárolnunk a részösz- 
szegeket, a függvényobjektumok sokkal kényelmesebbek a függvényeknél. 
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12. fejezet: Bevezetés a Crt szabványos sablonkönyvtárába 


Útmutató: Mielőtt nekilátnánk egy tároló bejárásához for ciklust írni, vizsgáljuk meg, nem 


tudunk-e tömörebb kódot írni a for. each algorítmus segítségével! Ha az eredeti ciklus törzsé- 
nek szánt kódrészletet függvényben vagy függvényobjektumban helyezzük el, azt átadva a 
for. each algoritmusnak sokszor azonos működést és tömörebb kódot érhetünk el. 


Rendezett vektor 


Ebben a fejezetben megmutatjuk, hogyan lehet egy vektort rendezetten tar- 
tani STL algoritmusok segítségével. Rögtön felmerül a kérdés, miért érdemes 
vektorban tárolni a rendezett adatokat, hogyha halmazban is lehetne, amely 
automatikusan rendezett. Való igaz, hogy a vektor esetén beszúráskor odébb 
kell léptetni az adatokat, míg egy bináris fában csak meg kell találni az elem 
helyét, és a fát alkalmanként ki kell egyensúlyozni. Törlésnél hasonlóan rossz 
a helyzet. Ugyanakkor a vektor kevesebb memóriát fogyaszt, és a rendezett 
vektoron a keresés is sokkal gyorsabban futhat. A kisebb memóriaigény keve- 
sebb laphibát jelent, ami meggyorsítja a vektor használatát. Ráadásul a fák 
nem folytonos memóriaterületen helyezkednek el, mint a vektor, így a fa be- 
járásakor a vektorhoz képest megnőhet a laphibák száma. 

Vagyis, ha a tároló használatában jól elkülönül a tároló felépítésének fá- 
zisa (beszúrás, törlés), illetve a tárolt elemek használata (keresés), akkor a 
rendezett vektor is jó döntés lehet.55 A törlési-beszúrási fázis alatt ugyanis 
rendezetlen a vektor, így a beszúrás gyors: mindig a végére kerül az új elem. 
Ezek után rendezzük a vektort. A használat alatt pedig bináris keresést al- 
kalmazva gyorsan megtalálhatjuk a keresett elemet. 

A vektor rendezését többek között a sort algoritmussal végezhetjük el: 





endO d; 


A sort algoritmusnak átadhatunk egy harmadik paramétert is, amely egy ösz- 
szehasonlítást elvégző, szigorú gyenge rendezést megvalósító predikátumra 
mutató pointer vagy függvényobjektum. Egész számok esetén erre nincs 
szükségünk. Azokat az algoritmusokat, amelyek megváltoztatják az elemek 
sorrendjét a megadott tartományban, sorrendváltoztató algoritmusoknak 
(mutating algorithms) nevezzük. 

Miután a vektort rendeztük, bináris keresést használhatunk annak meg- 
vizsgálására, hogy egy elem benne van-e a tárolóban. Mivel a vektor rende- 
zett, az egyes elemeket sorra vevő find algoritmus itt nem lenne hatékony, 
hiszen nem tudja kihasználni a rendezettség előnyeit. Így a binary. search al- 
goritmust használjuk. Az olyan algoritmusokat, amelyek rendezett iterátor- 
tartományt feltételeznek, rendezett tartományt feltételező algoritmusok- 
nak (sorted range algorithms) nevezzük. 


E 
5 Az [10] irodalom egy egész fejezetet szentel a kérdés alapos körbejárásának. 
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12.1. Alapkoncepciók 
zati 





Értelemszerűen ennek az algoritmusnak is megadhatunk egy összehasonlíi- 
tást végző műveletet utolsó paraméterként. 

Ha iterátort is szeretnénk visszakapni az elem első előfordulására, a 
lower. bound függvény használhatjuk: 





Ennek a visszatérési értéke csak kicsit hasonlít a find algoritmuséra. Ha 
benne van az elem a tartományban, akkor az első ilyen elemre mutató iterá- 
torral tér vissza. Ez eddig ugyanaz, mint a find visszatérési értéke. Viszont, 
ha az elem nem található, akkor nem a tartományt megadó második iterátor- 
ral tér vissza, hanem arra az első elemre mutató iterátorral, amely elé be kel- 
lene szúrni a keresett elemet. Tehát vagy visszatér a keresett elemre mutató 
iterátorral, vagy megadja, hol lenne a keresett elem, ha benne lenne a tarto- 
mányban. Ezért meg kell néznünk, érvényes-e az iterátor, majd azt, hogy 
tényleg a megadott értékre mutat-e. Mivel az STL csak a c operátor meglétét 
írja elő ilyen esetben, a — operátort sosem, ezért egy kis trükköt alkalma- 
zunk. Ha nincs benne a keresett elem, akkor az iterátor mindenképpen a ke- 
resett elemnél nagyobb elemre mutat, hiszen kisebb elem elé nem szúrhatjuk 
be. Vagyis, ha az iterátor nem nagyobb elemre mutat, akkor az algoritmus 
megtalálta a keresett elemet, ha nagyobbra, akkor nem találta meg. Ezért ezt 
a tulajdonságot használjuk a visszatérési érték vizsgálatánál. 

Természetesen a lower bound algoritmusnak is megadhatunk egy össze- 
hasonlítást végző műveletet. Fontos, hogy ha így tettünk, akkor ennek az az 
oka, hogy a típusnál megadott goperátor nem volt megfelelő. Ezért ilyenkor a 
megadott összehasonlítást végző műveletet kell használnunk a visszatérési 
érték vizsgálatánál is. Erre mutatunk példát az alábbi kódrészlet segítségével: 
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12. fejezet: Bevezetés a Css szabványos sablonkönyvtárába 


edes kimesz kezántettztsszásaztázetbattátálkzenomekékeetk Ae ezette... 





Ennél valamivel egyszerűbben lehet kiértékelni a keresés eredményét az 
egual range algoritmusnál, amelyet a 12.3.5. Rendezett tartományt feltételező 
algoritmusok fejezetben részletezünk. 

A dinamikus tömbben int típusú pointereket tárolunk. Beépített típusokra 
a gyakorlatban ritkán tárolunk pointert tárolókban, saját típus esetén azon- 
ban annál inkább, ezért ezt bevezető példának szánjuk. 

Elsőként megadjuk az összehasonlítást végző predikátumot. Erre azért 
van szükség, hogy ne a pointereket hasonlítsa össze, vagyis ne a memóriaci- 
meket hasonlítsuk össze, hanem a mutatott értéket. 

Ezek után meghívjuk a sort algoritmust, átadva neki a predikátumot. Ezzel 
a tömböt rendeztük a mutatott értékek szerint. A 3 első előfordulásának meg- 
keresésére a lower. bound algoritmust használjuk. Mivel itt pointert kell átad- 
nunk, változó címét adjuk át. Az algoritmus visszatérési értékét az int ptr. pred 
függvénnyel végezzük, hiszen a — operátor a memóriacímeket hasonlítaná össze 
teljes kavarodást okozva, az algoritmus viszont az értékeket hasonlítja össze. 

Mivel most pointerek vannak a tárolókban, és az iterátor maga is indírek- 
ciót képvisel, a tárolt pointerek mutatott értékeit két dereferencia operátorral 
("") érhetjük el. 

Az int ptr. pred függvény természetesen csak int típusra működik, és ez- 
zel a megoldással minden típusra új összehasonlítást írhatunk. Ezért érde- 
mes ezt a függvényt sablonná tenni: 








Ezzel a megoldással általánossá tettük a predikátumot. Természetesen függ- 
vényobjektumot is írhatunk ezzel a módszerrel: 





Az osztály példányát szokás szerint a konverziós értelmű konstruktorhívással 
állítjuk elő. A lower bound algoritmus visszatérési értékének vizsgálatakor 
operátor szintaxissal hívjuk a konstruktor által létrehozott példány zárójel 
operátorát. 

Ezek után a felszabadítást végző függvényobjektum-sablon egy lehetséges 
implementációja az alábbi: 









operator ()(const Type" ptr; 


hös 


const(de 
A fenti sablont pedig az alábbi módon használhatjuk a dinamikus tömb poin- 
terelemeinek a törlésére: 

7 forreach(numptrs .beginÖ ,numptrs .end() , delete ptrO) ; 


Befejezésül egy egyszerű algoritmust mutatunk, amellyel megfordíthatjuk a 
vektor elemeinek sorrendjét: 


[7 Teverse(numbers .beginO , numbers. endő) pi 


A reverse algoritmus természetesen nem követeli meg, hogy a vektor rende- 
zett legyen. 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 





k, hogy dinamikus tömbből elemet a 





A teljesség kedvéért megjegye: ALASKA MELLE 
remove algoritmus segítségével törölhetünk. Az alábbi példa kítörli az összeg 
olyan elemet a vektorból, amelynek értéke 3. 


jers. Z umbers .beginO , numbers.end() , 3) , 
tvápatáó let: Saottá ? numbers. end()) ; 


A remove algoritmust és a fentihez hasonló használatát a 12.3.3. pont alatt 
részletezzük. 


12.2. Függvényobjektumok" 


A függvényobjektumokkal a 12.1.3. részben ismerkedtünk meg. Ebben a feje. 
zetben megmutatjuk, hogyan használhatunk függvényobjektumokat az asszo- 
ciatív tárolók rendezési feltételeinek megadására. Ez azért különösen fontos, 
mert itt nem válthatjuk ki függvénymutatókkal az átadandó függvényobjek- 
tumokat. Az STL számos, már megírt függvényobjektumot bocsát rendelkezé- 
sünkre. Ezek nagy része aritmetikai és logikai műveleteket valósít meg, ame- 
lyek nagyon kényelmessé teszik az algoritmusok felparaméterezését. A függ- 
vényobjektumokat kombinálhatjuk egymással, egyes argumentumaik helyébe 
állandókat helyettesíthetünk. Ezt a függvényadapterek teszik lehetővé. Végül 
a tagfüggvény-adaptereket mutatjuk be, amelyek fontosságát az adja, hogy 
pointereket tartalmazó tárolók elemein végzett műveleteit ,továbbíthatjuk" a 
mutatott objektumnak. 





12.2.1. Asszociatív tárolók rendezése 


Az asszociatív tárolóknál láttuk, hogy a tárolt elem c operátorának néhány 
ésszerű szabályt betartó túlterhelésével egyszerűen megadhatjuk a rendezés- 
hez szükséges összehasonlító operátort. Ám nem mindig áll módunkban hoz- 
záférni a tárolandó elem típusához. Ennek leggyakoribb esete az, amikor po- 
intereket szeretnénk eltárolni. Erre főként akkor van szükség, ha polimorf vi- 
selkedést szeretnénk. Tekintsünk meg ehhez egy példát! 


Feladat: Egy egyszerű alakzatszerkesztő program rendezett tárolóban szeretné tartani a 
megrajzolt alakzatokat. A tárolóban a könnyű kirajzolás miatt első a leginkább a háttérben ta- 
lálható alakzat, az utolsó a legelöl helyet foglaló alakzat. Így elég a tárolón végighaladva ki- 
rajzolni az alakzatokat. Az alakzatnak van egy zOrder nevű" egész változója, amely a kétdi- 
menziós alakzatoknak azt a tulajdonságát adja meg, hogy mennyire vannak a háttérben: 0 a 
legelső alakzat, a legnagyobb érték jelenti a leghátsót. A tárolónak tehát a zOrder szerinti 


fordított sorrendben kell rendeznie az elemeket. Az alakzatból természetesen több alakzat ís 
származhat: téglalap, háromszög, kör stb. 





s Ha a kétdimenziós alakzatok koordinátáit x és y jelöli, akkor a takarást a képzeletbeli 
harmadik dimenzió menti elrendezés adja, amit 2-vel jelölünk. Így a zOrder a harmadik 
dimenzió mentén való rendezettséget jelenti. 
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12.2. Függvényobjektumok" 
Megoldás 
Tárolóként halmazt választunk, hiszen az bináris fában tárolja az elemeket, és 
automatikusan rendezi őket. Idézzük fel, hogy az STL tárolók beszúrófüggvé- 
nyei lemásolják az elemeket, vagyis csak az ősosztály része marad meg és kerül 
a tárolóba. Mivel a halmazban nemcsak az alakzat osztály (Shape) példányai 
tárolódnak, hanem a leszármazottaié is (Rectangle, Triangle stb. típusú objek- 
tumok), a tárolóban Shape" típusú pointereket fogunk tárolni. A pointerekre 
értelmezett a £ operátor, így a halmaz memóriacím szerint rendezi az objektu- 
mokat, nem pedig zÖrder szerint. Ezen kétféleképpen tudunk változtatni: 


e  Írunk egy csomagolóosztályt a pointernek, ahol átdefiniáljuk a c ope- 
rátort, hogy a mutatott érték zOrder-je alapján végezze az összeha- 
sonlítást. 


e  ,Rábeszéljük" a halmaz osztályt, hogy az összehasonlításhoz egy álta- 
lunk megadott függvényobjektumot használjon. 


Az első megoldás elég nehézkes, és nem is túl elegáns: számos operátort át 
kell írni, hogy a csomagolóosztály tényleg úgy viselkedjen, mint egy mutató. 
Így a második megoldást választjuk. A keresőalgoritmusokat kétféle módon is 
,rábeszélhetjük", hogy ne az elem c operátorát használja: meg kell adnunk 
egy predikátumot vagy egy függvényobjektumot. A halmaz kötelezővé teszi a 
második megoldás alkalmazását, ugyanis csak a függvényobjektum típusát 
adhatjuk meg. Figyeljük meg a halmaz deklarációját: 


. template c 
e CTáss key, 
class Traitsz-lessckeys, 
. —— class Allocatorsallocatorckeyz 


2 § 
. class setf...) 


A második sablonparaméterként adhatjuk meg a függvényobjektum típusát 
- nem a példányát, ahogy az algoritmusoknál tettük —, és ezt példányosítja, 
majd használja a tároló az elemek rendezéséhez. Az előző (Rendezett vektor) 
fejezetben egy egyszerűbb példán bemutattuk, hogyan lehet úgy általános 
függvényobjektum-sablont írni, hogy a pointer típusú elemek közötti rende- 
Zést ne a memóriacímek alapján, hanem a mutatott típus alapján végezze el. 
A sablon felhasználásával egyszerűen megoldhatjuk a rendezést. Először fe- 
lülírjuk a Shape osztályban a c operátort: 





:(unsigned zorder) :zorder(zorder) (li fealggatáják 
irtual void drawO-0; 
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bool operator c (const Shapeg other)const ttégei 
e. (return zorder c other.zorder;) so 


void print() (couteczordercsend; ) 
virtual -ShapeO(); 
h 


A Shapc osztályból leszármaztatjuk a feladatban előírt osztályokat: 


class Rectangle: public Shape 
( 

unsigned a,b; 
public: 
Rectangle(unsigned zorder, unsigned a-0, 

unsigned b-0):a(a),b(b) , Shape(zorder) (3; 

void draw()(); 
pg 


class Triangle: public Shape 

1 
unsigned a,b,c; 

public: 
Triangle(unsigned zorder, unsigned a-0, unsigned b-0, 

unsigned c-0) :a(a) ,b(b) , c(c) , Shape(zorder) (3 ; 

void draw) (b; 

n 


Majd létrehozzuk a halmazosztályt, és a paraméterében megadjuk az előző 
(Rendezett vektor) fejezetben megírt compare ptr by value osztályunkat. 


setShape" , compare ptr. by. values shapes; 
typedef setcShape"r, compare. ptr.by. values::iterator shape iterator; 


Mivel az iterátor típusa elég hosszúvá válik, ezért egy típusdefiníción keresz- 
tül egyszerűbb és talán olvashatóbb névvel hivatkozunk rá. 

Ezek után tetszőleges sorrendben létrehozzuk az elemeket, és berakjuk a 
tárolóba: 


shapes.insert(new Rectangle(1)); k 
shapes.insert(new Triangle(2)) ; 7 Suzjábi 
shapes.insert(new Rectangle(0)); 


A kiíratásánál látjuk, hogy a halmaz valóban a zOrder változó alapján állapí- 
totta meg az elemek sorrendjét: 


forCshape i 
1 





A keresés szintén a megadott függvényobjektum által megadott összehasonlí- 
tást jelenti. 
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SöPatÖL 72 angle(2)); 





A fenti kódrészletben a konverziós konstruktor által létrehozott ideiglenes ob- 
jektumra adunk át egy pointert, amely ideiglenes természetéből fakadóan 
konstans. Mivel az összehasonlítás csak a zOrder tagváltozót veszi figyelem- 
bé; visszakapunk egy iterátort a 2-es zOrder-rel rendelkező háromszögre. Ha 
ezt nem szeretnénk, az összehasonlításnál figyelembe kell venni a típust is, 

éldául a leszármazottak által felülírt virtuális függvénnyel, amely visszaad- 
az adott alakzat típusának azonosítóját. 

Ha a Shape ősosztály draw tagfüggvényét nem tesszük tisztán virtuális- 
sá, hanem üresen hagyjuk a törzsét, akkor azt is példányosíthatjuk, és jóval 
elegánsabb lesz a fenti kód: 


ja 


shape-iterator position-shapes . find(€Shape(2)) ; 
.Gposition) oprintO; // 2 


A fenti módszer minden asszociatív tárolóra alkalmazható: mindegyiknek van 
egy sablonparamétere, ahol egy összehasonlítást végző függvényobjektum- 
típust adhatunk meg. 

Fontos, hogy a tárolóban lévő pointerek felszabadításáról se feledkezzünk 
meg. Ezt nagyban leegyszerűsíti előző (Rendezett vektor) fejezetben megírt 
delete ptr függvényobjektum-sablon: 


for. each(shapes. begin() , shapes.end() , delete ptrO); 


Az eddigiek alapján levonhatjuk a következtetést, miszerint két sablon segít- 
ségével nagyon egyszerűen és főként biztonságosan használhatjuk az STL tá- 
rolókat polimorf osztályok objektumainak érték szerint rendezett tárolásához. 


12.2.2. Előregyártott függvényobjektumok 


Az előző fejezetben adósak maradtunk azzal, hogy elmagyarázzuk a set osz- 
tály második paraméterének alapértelmezett beállítását. 


template c 
class Key, 
class Traits-lesscKeyz, 


class Allocatorzallocatorckeyz 
z 


class setf...) 


Említettük, hogy a második sablonparaméter kötelezően függvényobjektum- 
típus, ezért a lesscKey2 is függvényobjektum. Az STL számos hasonló, előre 
megírt függvényobjektumot bocsát rendelkezésünkre. Ezek a functional állo- 
mányban találhatók. 
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A less függvényobjektumnak két paramétere van, és a zárójel operátor 
akkor tér vissza igaz értékkel, ha a param 12£param2 igaz a két paraméter kö. 
zött. Vagyis a less az c operátort csomagolja be, és teszi függvényobjektum. 
ként is elérhetővé az algoritmusok és tárolók számára. Nézzünk meg egy le. 
hetséges implementációt! 







templatecclass Types 
öles; Tessz a JEL 


ké a VEG. ÉLESEN 


sa operator() (const Type: Left, const TypeG Right) co 
return (Left c Right); jgékés o hígssi 
) d 


Az asszociatív tárolóknál láttuk, hogy általában ez az alapértelmezett rende- 
zés, ami megfelel az STL alapelveinek: az c operátor által biztosított szigorú 
gyenge rendezést használja alapértelmezettként. 

Vannak egyparaméterű függvényobjektumok is. Ilyen a negate, amely nem 
logikai negálást hajt végre, hanem előjelet vált: a -param értékkel tér vissza, 
A logikai negálást a logical not függvényobjektum valósítja meg, amely a 
Iparam értékkel tér vissza. 

Az alábbiakban felsoroljuk az STL függvényobjektumait. 

Összehasonlító műveletek 
Az alábbi lista összefoglalja az összehasonlító függvényobjektumokat, zárójel- 
ben megadva a becsomagolt operátort: 

e — egyenlő: egual to (- - 

s — nem egyenlő: not egual to (17) 

e — nagyobb: greater (2) 

e — kisebb: less (2) 

e — nagyobb egyenlő: greater egual (27) 

. — kisebb egyenlő: less egual (c-) 

Aritmetikai műveletek 

Az aritmetikai függvényobjektumok az aritmetikai operátorokat csomagolják be. 
e — összeadás: plus (4) 
e — kivonás: minus (-) 


e — szorzás: multiplies (") 





12.2. Függvényobjektumok" 
e ÜLÜNK ETTEK én dtám szarsz mais seret DÓ 
e osztás: divides () 
e  maradékos osztás maradéka: modulus (96) 
e — mínusz előjel: negate (egyargumentumú -) 


Logikai műveletek 


A logikai műveletek nem a bitenkénti műveletekeket zárják égbe, hanem 
a gé, II és ! operátorokat. egységi 


e logikai ÉS: logical and (8-8) 
e logikai VAGY: logical or (11) 
e logikai tagadás: logical not (!) 


Függvényadapterek 


A függvényadapterek (function adapters) függvényobjektumok összekombi- 
nálását teszik lehetővé. Idézzük fel a 12.1.3. Algoritmusok fejezet Műveletek 
mint algoritmusargumentumok részében említett find if algoritmust, amely 
egy tartományt vár, illetve egy predikátumot, és a legelső olyan elemmel tér 
vissza, amelyre a predikátum igaz! Mivel ahol predikátum használható, ott 
függvényobjektum is, az eddigi függvényobjektumok is felhasználhatók kere- 
sési feltételként. 





Feladat: Tekintsünk adottnak egy vektorobjektumot, amely egész számokkal lett feltöltve! 
Keressük meg az első olyan elemet, amely nagyobb vagy egyenlő, mint 3! 


Megoldás 

Az összehasonlító műveleteknél láttuk, hogy létezik egy greater egual függ- 
vényobjektum, amely a 2- műveletet zárja egységbe, vagyis két paramétert 
vár, és akkor tér vissza, ha param1 57 param2. A problémánk annyi, hogy a 
find if csak egy paramétert ad át, az aktuális elemet (esetleg érdemes a 
find if algoritmusnál bemutatott is odd függvényobjektumnak a 12.1.3. Algo- 
ritmusok fejezet Műveletek mint algoritmusargumentumok részében található 
példájához visszalapozni). 

A megoldáshoz tehát szeretnénk egy olyan csomagolóosztályt, amely 


s a konstruktorában átveszi a greater egual függvényobjektumot és a 
3-at paraméterként, 
s a zárójel operátora átveszi az aktuális elemet, valamint 


s a zárójel operátora visszatér a greater. egual(3, aktuális elem) kifeje- 
zéssel. 
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Általánosabban fogalmazva szükségünk van egy olyan osztályra, amely 


e. a konstruktorában átvesz egy / függvényobjektumot és annak egy a 
argumentumát, 


s — a zárójel operátora átvesz egy e elemet, valamint 


s — a zárójel operátor az f függvényobjektum első paraméteréhez az a ar. 
gumentumot, a második paraméteréhez az e elemet köti, és az f visz. 
szatérési értékével tér vissza: return f(a,e). 


Pontosan ezt csinálja a binder2nd osztály, amelyet a bind2nd algoritmussal 
hozhatunk létre. Ennek a deklarációja az alábbi: 


templatexclass Operation, class Typez 
binder2nd operation; bind2nd( 

const Operation Func, 

const Typeg Right X 

§ Ag 

Elsőként megadjuk a függvényobjektumot, másodiknak pedig a függvényob- 

jektumnak szánt második, jobb oldali paramétert. Így a feladat alábbi megol- 

dásához jutunk: 


position-find, if(numbers . begin() ,numbers . end() , met) 
bindznd(greater. egualcint:() , 39); 
if(position!snumbers , end()) 4 
VES SZEGNÜBE " ez "position; // Megvan: 3 
else 
cout cc "Not found,"; 


Ha az első paramétert akarjuk egy adott értékhez kötni, akkor a bind1Ist függ- 
vényt használjuk. Összegezve: a bindIst és bindond függvények által vissza- 
adott függvényobjektumok — nevezetesen a binderlIst és a binder?nd — szaba- 
don hagynak egy paramétert, és lekötnek egy másikat tetszőleges kétargu- 
mentumú függvényobjektumra. A lekötött paramétert a konstruktorban ve- 
szik át, akárcsak a kétargumentumú függvényobjektumot. A bindiIst az első 
paramétert, a bind2nd a második paramétert köti le. Ezt a megoldást termé- 
szetesen tetszőleges függvényobjektumra alkalmazhatjuk. 
További logikai függvényadapterek az alábbiak: 


e  notl 
e  not2 


A not! egy egyargumentumú predikátum tagadását állítja elő, a not2 kétar- 
gumentumú predikátumét. Az előző példa módosításában ezúttal az első 
olyan elemet keressük meg, amely 3-nál kisebb. 
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LK ÉRÉS 5 rtttrmetágy notI(bindzndégreater egvalcint O 3); 


Eddig a függvényobjektumokat úgy tárgyaltuk mint a függvények általánosí- 
tásait. Ezek a függvényobjektumok azonban valamivel többet tudnak: néhány 
típusdefiníciót is tartalmaznak, amelyet néhány helyen elvár tőlünk az STL. 
Ezeknek a típusdefinícióknak (például argument type, first argument type, 
second argument type és result type) nincs különösebb jelentőségük, elég 
annyit megértenünk, hogy az STL-nek szüksége van rájuk. Viszont ez azt je- 
lentené, hogy ahol az STL függvényobjektumot vár, és feltételezi a fenti tí- 
pusdefiníciók közül néhánynak a meglétét, ott nem adhatunk át normál függ- 
vényeket. Természetesen erre is van megoldás: a ptr. fun adapter. Ezzel be- 
csomagolva a függvényeket a megfelelő típusdefiníciók is a rendelkezésre áll- 
nak. Nézzünk egy példát: 


vectorxconst char"5::iterator position - find if(names.beginŐ , 
names .end() , noti(bind2nd(ptr. funCstrcmp) , "Kant"))); 
if(position !- names.end()) 
cout cc "Found: " cc "position; // Megvan: Kant 
else 
cout cc "Not found."; 


Mivel az stremp pontosan akkor tér vissza nullával, amikor a két sztring egyen- 
lő, ezért a notl függvényobjektumra is szükségünk van. Jól látható, hogy a 
ptr fun függvényobjektummal egy szabványos C függvényt is könnyen fel- 
használhatunk. Ha viszont elhagynánk ezt a csomagolósablont, hibaüzenete- 
ket kapnánk. 


Tagfüggvény-adapterek 


Térjünk vissza a 12.2.1. Asszociatív tárolók rendezése fejezetben bevezetett 
alakzatos példához! A kiíratást az alábbi kódrészlettel végeztük: 


for(shape.iterator it - shapes.beginO;it !- shapes.endO;trtrit) 
ül 


(Ctit)-oprintO; //012 


Most már ismerjük a for. each algoritmust, természetes, hogy szeretnénk el- 
kerülni a terjengős for ciklusokat. Másrészt a Shape osztálynak van egy print 
tagfüggvénye, és az objektumorientált szemlélet elvárná, hogy tagfüggvénye- 
ket is tudjunk hívni, ne csak globális függvényeket vagy külső függvényobjek- 
tumokat. Ugyanakkor, emlékezzünk vissza a for. each algoritmus a 12.1.3. 
Algoritmusok fejezet Műveletek mint algoritmusargumentumok részében ta- 
lálható kódjára, amikor láttuk, hogy az algoritmus a műveletként kapott sab- 
lonparaméter után egy zárójelet ír, benne az aktuális elemmel, és így hívja meg 
a megadott műveletet. Hogyan lehet meghívni egy tagfüggvényt fv(objektum) 
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szintaxissal? Az fu helyébe természetesen egy okos függvényobjektumot 
csempészünk, amely már eltárolta a tagfüggvényt, és az átadott objektummal 
összekombinálva meghívja. A következő kérdés természetesen az, hogyan jö 
het eltárolni egy tagfüggvényt, illetve ,összekombinálni" egy objektummal 
úgy, hogy az objektumnak az adott tagfüggvénye hívódjon meg? Idézzük fel a 
6.6. A pointer-tag operátorok fejezetben található -2" és ." operátorokat! Ezek 
az operátorok egyfelől egy objektumot várnak (vagy egy mutatót az objektum. 
ra), illetve egy tagfüggvénypointert. Így a függvényobjektumunk átvesz egy 
tagfüggvényre mutató pointert, és a megkapott aktuális elemmel és a -5r 
operátorral (most az aktuális elem pointer, hiszen Shape típusú pointereket 
tárolunk) végrehajtja a tagfüggvény meghívását. Pontosan ezt implementál- 
ták az STL mem fun (member function, tagfüggvény) függvényobjektumában. 
A kód így nagyon egyszerűvé válik: 


for.each(shapes . begin() , shapes . end) , mem fun(€Shape: :print))g 


Láttuk, hogy a mem fun a -2" operátort csomagolja be. A .? operátort, amely- 
re akkor van szükség, ha nem pointereket tárolunk a vektorban, hanem ob- 
jektumokat, a hasonló paraméterezésű mem fun. ref függvényobjektum zárja 
egységbe."7 


12.3. Szabványos algoritmusok" 


Láttuk, hogy az algoritmusok lényegében globális sablonfüggvények az std 
névtérben. Az objektumorientált megközelítés szempontjából igyekszünk ke- 
rülni a globális függvényeket. Az STL készítői megtehették volna, hogy egy 
osztály statikus tagfüggvényeivé teszik ezeket az algoritmusokat. De nem tet- 
ték, mert az STL nem teljesen az objektumorientált paradigmát követi: a ge- 
nerikus programozás elemeit is felhasználja. 

Generikus programozás [11] alatt az STL alkotói az algoritmusok és az 
adatstruktúrák általános és absztrakt definícióját értik, amely lehetővé teszi, 
hogy összetartozó programozási feladatokat egyszerre végezzünk el. Ennek 
központi elgondolása, hogy a generikus algoritmusok egyfajta eljárássémák- 
ként foghatók fel, amelyek teljesen függetlenek azoktól az adatstruktúráktól, 
amelyekkel dolgoznak, és amelyek hatékony konkrét algoritmusokból általá- 
nosíthatók. 





"7 A kissé inkonzisztens elnevezés annak tudható be, hogy az STL írásakor először a pointereket 
tartalmazó tárolóknál merült fel, és ott elnevezték mem fun-nak. Amikor később az objektu- 
mokat tartalmazó tárolók esetén is szükségessé vált a tagfüggvényelérés, már nem lehetett 
megváltoztatni az eredeti függvényobjektumot, így ez jobb híján a mem fun ref nevet kapta. 
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Eddigi példánkban a másoló algoritmusnak csak az iterátorok ismeretére, 
működésére volt szüksége, az adott tároló belső felépítéséről semmit sem tú 
dott. Ugyanúgy alkalmazhatjuk set-re, mint vector-ra. Vagyis a vector, a set és 
más tárolók elemeinek másolását, mint összetartozó feladatokat az STL egy 
függvényben oldja meg, amelyhez sablonfüggvényeket használ. A copy algo- 
ritmus a vector és a set hatékony másolófüggvényeinek egyfajta közös általá- 
nosítása. Érdemes észrevennünk, hogy a sablonok generikus iterátorokkal 
dolgoznak, amelyek eléggé általánosak, hogy csak a szükséges műveleteket, 
illetve adattagokat tartalmazzák, viszont elég speciálisak ahhoz, hogy fordítás- 
idejű hibát adjanak, ha valamelyik előkövetelmény (művelet/adattag) mégsem 
áll rendelkezésre a specializáció után. 

Említettük, hogy az algoritmusok mindig egy iterátortartományon végez- 
nek műveleteket. A további rugalmasság érdekében az algoritmusoknak 
megadhatunk függvénymutatókat, illetve függvényobjektumokat (12.1.3. AL- 
goritmusok fejezet Műveletek mint algoritmusargumentumok rész) is. Például 
ezeket a függvényobjektumokat használhatjuk keresési (find if) vagy rende- 
zési feltételként (sort), meghatározhatjuk, hogy melyik elemet hogyan dolgoz- 
zuk fel (for. each). Ha a függvények vagy a függvényobjektumok 0 operátora 
bool értékkel tér vissza, akkor azokat predikátumoknak (12.1.3. Algoritmusok 
fejezet Műveletek mint algoritmusargumentumok rész) hívjuk. 

Nem minden algoritmust használhatunk tetszőleges tárolóval. A sort al- 
goritmus például nem működik asszociatív tárolón, hiszen ezekben a tárolók- 
ban a sorrendet nem határozhatjuk meg az iterátorokon vagy a tagfüggvé- 
nyeken keresztül. Nem minden tárolóra érdemes algoritmust használni. Pél- 
dául az asszociatív tárolók esetén az elemeken végigiteráló find algoritmus 
sokkal lassabban talál meg egy kulcsot, mint a rendezettséget figyelembe vevő 
find tagfüggvény. 


Útmutató: Mindig részesítsük előnyben az egyes tárolók tagfüggvényeit az általános algorit- 


musokkal szemben! 





12.3.1. Az algoritmusok áttekintése 


Az algoritmusok elnevezésében két konvenció érvényesül. Az . if végződésű 
algoritmusoknak létezik egy utótag nélküli verziója is ugyanilyen számú pa- 
raméterrel. A végződés nélküli algoritmus érték alapján dolgozik, az if vég- 
ződésű pedig az érték helyett függvénypointert vagy függvényobjektumot vár. 
Például a find egy adott értékű elem első előfordulását keresi meg, a find if 
egy függvény vagy egy függvényobjektum által meghatározott keresési felté- 
tel alapján keresi meg az első elemet. A . copy utótag azt jelzi, hogy a függ- 
vény nem a bemeneti iterátortartományon hajtja végre az adott műveletet, 
hanem átmásolja az eredményt. Például a replace algoritmus kicseréli az Ösz- 
Szes adott értékű elemet, a replace. copy változatlanul hagyja a bemeneti tar- 
tományt, és létrehoz egy kimeneti tartományt, ebben lesznek kicserélve az 
elemek, A replace if esetén a kicserélendő elemeket művelettel adhatjuk meg, 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 





a replace. copy. if esetén művelettel adhatjuk meg a kicserélendő elemet, és a 
csere a kimeneti tartományon lesz végrehajtva. Az n utótag az első n elem. 
mel kapcsolatos műveletvégzésre utal. A fill kicseréli egy tartomány Összeg 
elemét a megadott értékre, a fill n csak az első n elemét. 

Emlékeztetünk rá, hogy az algoritmus kimenete számára megadott iterá. 
tortartományt az algoritmus felülírja, és nekünk kell gondoskodnunk róla, 
hogy elég helyet foglaljunk a kimeneti tartományban. A másik alternatívát a 
beszúrók használata jelenti, amelyet a 12.1.2. rész tárgyalt. 


Útmutató: Mindig biztosítsunk helyet az algoritmus kímeneti tartományában, vagy használ. 


junk beszúrókat! 





Az algoritmusok kimeneti tartományként általában csak egy iterátort vár- 
nak, mert a bemeneti adatok egyértelműen meghatározzák a kimeneti tarto- 
mány nagyságát. 

Az algoritmusokat az alábbi, a 12.1.3 pontban már bevezetett kategóriák, 
illetve két új kategória alapján tárgyaljuk: 

e — nem módosító algoritmusok 

e módosító algoritmusok 

e — sorrendváltoztató algoritmusok 

e rendezett tartományt feltételező algoritmusok 


e — numerikus algoritmusok 


Az utolsó előtti kategória átlapolódik az első hárommal, ugyanakkor az előfel- 
tételük annyira fontos, hogy külön csoportba soroljuk őket. A numerikus al- 
goritmusok a numerikus számítások programozását teszik egyszerűbbé. A to- 


vábbiakban áttekintés gyanánt rövid magyarázatokkal felsoroljuk az egyes 
algoritmusokat. 


Mivel a nem módosító algoritmusok sem a tárolóban lévő elem értékét, 
sem a sorrendjét nem változtatják meg, a tartományt kijelölő iterátorok be- 
meneti, illetve előreléptető iterátorok. Ezek az alábbiak: 

s count: megszámolja a megadott értékű elemeket 


" count if. megszámolja az elemeket, amelyek megfelelnek az adott fel- 
tételnek 


. — min element: megkeresi a minimális elemet 
" max element: megkeresi a maximális elemet 


e — find: megkeresi egy elem első előfordulását 
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12.3. Szabványos algoritmusok" 
Szat ES THEN ezer zoo 


av sfindáfi megkeresi egy elem első előfordulását, amely megfelel az adott 
feltételnek 


a search .n: megkeresi az első n egymás után következő adott értékű 
elemet 


e — search: megkeresi egy résztartomány első előfordulását 
e find end: megkeresi egy résztartomány utolsó előfordulását 


e find first of. az első intervallumban megkeresi a második interval- 
lumban megadott elemek bármelyikét 


e  adjacent find: megkeres két szomszédos elemet, amely megfelel egy 
adott kritériumnak, vagy egy megadott értékkel egyenlő 


e  egual: megvizsgálja, hogy két tartomány megegyezik-e 
e — mismatch: megkeresi két tartomány első különböző elemét 
e  lexicographical compare: megvizsgálja, hogy az első tartomány előbb 


következik-e az ábécében (kisebb-e), mint a második, elemenként vé- 
gezve az összehasonlítást. 


A módosító algoritmusok módosítják a tartomány elemeinek értékét, vagy 
lemásolják őket. Ezért az az iterátortartomány, amelyet az algoritmus módo- 
sít, nem mutathat asszociatív tárolók elemeire. A módosító algoritmusok a 
következők: 


e for each: végrehajt egy műveletet az elemeken (ez nem módosító algo- 
ritmus is lehet, ha a művelet nem változtat az elemeken, illetve azok 
sorrendjén) 

9 copy: lemásolja a megadott tartományt 

e copy backward: lemásolja a megadott tartományt fordított sorrendben 


e  transform: módosítva lemásolja az elemeket; egy vagy két bemeneti 
tartománya lehet. 


e swap ranges: megcseréli két tartomány elemeit 


e fill: a tartomány minden elemét kicseréli a megadott értékre (feltölti a 
megadott tartományt egy adott értékkel) 
e  fill n: kicseréli a tartomány első n elemét a megadott értékre 
,  generate: a tartomány minden elemét kicseréli egy művelet visszaté- 
rési értékére 
fi ze 4 ű i té- 
,  generate n: kicseréli a tartomány első n elemét egy művelet vissza 
rési értékére 
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12. fejezet: Bevezetés a Cst szabványos sablonkönyvtárába 


e replace: a tartomány adott értékű elemeit kicseréli egy megadott ér. 
tékre 

e replace if. a tartomány adott feltételnek megfelelő elemeit kicseréli 
egy megadott értékre 

e replace copy: lemásol egy tartományt annak adott értékű elemeit ki. 
cserélve egy megadott értékre 

e replace copy. if: lemásol egy tartományt annak egy adott feltételnek 
megfelelő elemeit kicserélve egy megadott értékre 

e — remove: logikai törlést valósít meg: az eltávolítandó elemeket felülírja 
a soron következő el nem távolítandó értékekkel. Nem változtatja meg 
az elemek számát, de a visszaadott iterátortartomány csak az érvé- 
nyes elemekre mutat. 


e — remove if: működése megegyezik a remove algoritmussal, de itt a ki- 
cserélendő elemet művelet határozza meg 


e — remove copy: működése megegyezik a remove algoritmussal, de a vál- 
tozások a visszaadott tartományban érvényesülnek 


s remove copy if. működése megegyezik a remove copy algoritmussal, 
de itt a kicserélendő elemet művelet határozza meg 


e — unigue: két egyenlő szomszédos elem közül az egyiket törli a remove 
algoritmusnál ismertetett módon 


e — unigue copy: átmásolja a tartományt úgy, hogy a két egyenlő szom- 
szédos elem közül az egyiket törli a remove algoritmusnál ismertetett 
módon 


A sorrendváltoztató algoritmusok megváltoztatják az iterátortartomány ele- 
meinek sorrendjét, így ezek sem alkalmazhatók asszociatív tárolók iterátoraira. 
Ezek az algoritmusok az alábbiak: 


. reverse: megfordítja az elemek sorrendjét 


e reverse copy: ugyanaz, mint a reverse, de a változások a visszaadott 
tartományban érvényesülnek 


e — rotate: egy megadott iterátortól kezdve kilépteti az elemeket a tároló- 
ból, a hátul kiléptetett elemeket a tároló elejére teszi; tulajdonképpen 
megcserél két szomszédos tartományt 


,  rotate copy: működése megegyezik a rotate algoritmussal, de a válto- 
zások a visszaadott tartományban érvényesülnek 


", next permutation: az ábécérend szerinti következő permutáció 





prev. permutation: az ábécérend szerinti előző permutáció 


random. shuffle: véletlenszerűen elrendezi az elemeket a beépített 
vagy egy megadott véletlenszám-generátorral 


partition: a megadott predikátum által kiválasztott elemet a tarto- 
mány elejére teszi 


stable partition: ugyanaz, mint a partition, csak megőrzi az ekviva- 
lens elemek relatív sorrendjét 


sort: rendezi az összes elemet 


stable. sort: rendezi az összes elemet megőrizve az ekvivalens elemek 
relatív sorrendjét 


partial sort: részleges rendezés; addig rendezi az elemeket, amíg az 
első n elem helyes 


partial sort copy: ugyanaz, mint a partial sort, de a változások a 
visszaadott tartományban érvényesülnek 


nth. element: beállítja az n-edik elemet a megfelelő helyre; alatta az 
azt megelőző elemek vannak tetszőleges sorrendben, fölötte az utána 
következő elemek tetszőleges sorrendben 


make. heap: egy tartományt kupaccá alakít 
push heap: hozzáad a kupachoz egy elemet 
pop. heap: eltávolít egy elemet a kupacból 


sort heap: rendezi a kupacot 


A rendezett tartományt feltételező algoritmusok bemenete értelemszerűen 
rendezett tartomány, ezt a legtöbb STL implementáció nyomkereső üzem- 
módban ellenőrzi is. Ebben a kategóriában az STL a következő algoritmuso- 
kat biztosítja: 


merge: összefésül két rendezett tartományt; az eredmény egy rende- 
zett tartomány, amelynek elemei az egyes tartományok elemei 

inplace merge: összefésül két egymás után következő rendezett tar- 
tományt; az eredmény egy rendezett tartomány, amelynek elemei az 
egyes tartományok elemei 


binary search: megállapítja, hogy az intervallum tartalmaz-e egy 
elemet 


lower bound: megkeresi az első olyan elemet, amely nagyobb vagy 
egyenlő, mint a megadott érték 


upper. bound: megkeresi az utolsó olyan elemet, amely nagyobb vagy 
egyenlő, mint a megadott érték 
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12. fejezet: Bevezetés a Crr szabványos sablonkönyvtárába 


e egual range: megadja azt a tartományt, amelynek minden tagja meg- 
egyezik a megadott értékkel 


e includes: megadja, hogy az egyik tartomány elemeiből alkotott halmaz 
részhalmaza-e a másik tartomány elemeiből alkotott halmaznak 


e set union: kiszámolja két rendezett tartomány elemeiből alkotott 
halmaz unióját; a visszaadott tartomány rendezett, és minden eleme 
egyedi 


e. set intersection: kiszámolja két rendezett tartomány elemeiből alko- 
tott halmaz metszetét; a visszaadott tartomány rendezett, és minden 
eleme egyedi 


e — set difference: kiszámolja két rendezett tartomány elemeiből alkotott 
halmaz különbségét (azok az elemek, amelyek csak az első halmazban 
szerepelnek, a másodikban nem); a visszaadott tartomány rendezett, 
és minden eleme egyedi 


e — set symmetric difference: kiszámolja két rendezett tartomány elemei- 
ből alkotott halmaz szimmetrikus különbségét (azok az elemek, ame- 
lyek csak az egyik halmazban szerepelnek, a másikban nem); a visz- 
szaadott tartomány rendezett, és minden eleme egyedi 


A numerikus algoritmusok az alábbiak: 


e — accumulate: alapértelmezésben kiszámolja a megadott tartomány 
elemeinek összegét; az összeg tetszőleges művelettel lecserélhető 


e.  inner product: alapértelmezésben kiszámolja két tartomány skaláris 
szorzatát: az azonos pozíciójú elemek szorzatát képezi, és a szorzato- 
kat összegzi; a szorzat és az összegzés művelete lecserélhető 


e  adjacent difference: alapértelmezésben kiszámolja egy tartomány 
szomszédos elemeinek különbségét, és a visszaadott tartományba töl- 
ti; a különbség művelete lecserélhető 


e partial sum: alapértelmezésben a kimeneti tartomány i-edik eleme a 


bemeneti tartomány első i elemének az összege; az összegző művelet 
lecserélhető, 


A felsorolt algoritmusok nagy részét az eddig megismert algoritmusokhoz ha- 
sonlóan kell használnunk, az eddig megismert koncepciók és az STL verziónk- 
hoz tartozó dokumentáció segítségével hívásuk nem okoz különösebb nehéz- 
séget. A későbbiekben főleg azokat az algoritmusokat tárgyaljuk különösen 
nagy súllyal, amelyeknek szokatlan paraméterezése vagy feladata van, idioma- 


tikus használata jó szolgálatot tehet, illetve amikor több, nagyon hasonló funk- 
ciójú algoritmus közül kell választanunk. 
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12.3.2. Nem módosító algoritmusok 


A min. element és a max element függvényeket már ismerjük a 12.1.3. részből: 
ezek a tartomány legkisebb és legnagyobb elemét keresik meg. Ebben a fejezet- 
ben további algoritmusokat mutatunk be: megvizsgáljuk, hogy milyen algorit- 
musok állnak rendelkezésre, ha rendezetlen tartományban szeretnénk keresést 
végezni, valamint hogyan tudunk összehasonlítani iterátortartományokat. 


Keresés rendezetlen tartományokban 


A nem módosító algoritmusok közül valamilyen keresést valósítanak meg a kö- 
vetkezők: count, count if, search n, search, find, find if, find end, find. first of 
és adjacent find. Ezek mindegyike rendezetlen tartományon dolgozik, és 
egyenlőséget használ, nem ekvivalenciát. Rendezetlen tartomány esetén az 
algoritmus kénytelen sorra venni az összes elemet. Vagyis, ha a tartomány 
rendezett, akkor hatékonyabb a rendezett tartományt váró keresési algorit- 
musok használata, amelyeket a 12.1.3. rész tárgyal. 

Azoknak a függvényeknek, amelyeknek nincs . if utótagú megfelelőjük, két- 
féle verziójuk létezik. Az egyik az elemek — operátorát használja összehasonlí- 
tásra, a másik egy paraméterként megadható kétargumentumú predikátumot. 
Ez különösen hasznos, ha pointereket tárolunk, az összehasonlítást viszont a 
mutatott értékek alapján szeretnénk elvégezni. Ekkor felhasználhatjuk a 12.1.3. 
Algoritmusok fejezet Rendezett vektor részében bemutatott sablonokat. 

A továbbiakban feltételezünk egy egészeket tartalmazó vektort, amelyet 
egy nem rendezett sorozattal töltöttünk fel, illetve annak iterátortípusát: 


. int data[]-(4,2,1,3,1,3,3,2,1,3,3); 






ectorcints v(data,datatsizeof(data)/sizeof(data[0])); 
typedef vectorcints::iterator int iterator; 





Ebben a vektorban az elemek pozíciójára a továbbiakban nullától számozott 
indexszel hivatkozunk. 

A find algoritmust már ismerjük a 12.1.3. Algoritmusok fejezet Néhány 
egyszerűbb algoritmus részéből, a find if algoritmust a 12.1.3. Algoritmusok 
fejezet Műveletek mint algoritmusargumentumok rész tárgyalta. Emlékezte- 
tőül mutatunk egy példát, amely megkeresi a hármas szám első előfordulá- 
sát. A függvény a hármas indexű elemre mutató iterátort ad vissza, melynek 
mutatott értéke is három. 


, Antiiterator p3 - find(v.begin( ,v.end() , 3); 
Nemcsak egy adott értékkel megegyező elemet kereshetünk, hanem keresési 
feltételt is megadhatunk. A find. if algoritmus támogatja ezt a lehetőséget. 


Estünkben megkeressük az első háromnál kisebb elemet. A függvény az egyes 
indexű elemet adja vissza, amelynek értéke kettő. 
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12. fejezet: Bevezetés a Cr szabványos sablonkönyvtárába 


Ha azt szeretnénk tudni, hogy egy adott elem hányszor fordul elő az iterátor. 
tartományban, akkor a count algoritmust használjuk. Az alábbiakban meg- 
számoljuk, hány hármas található a megadott tartományban. Az algoritmus 
visszatérési értéke 5. 





Harta ező 


. count(v.beginO ,v.endO , 3); 





Ez az algoritmus is általánosítható. A count if megszámolja azokat az eleme. 
ket, amelyek eleget tesznek egy megadott feltételnek. Példánk feltétele to- 
vábbra is az, hogy az elem háromnál kisebb legyen. Az algoritmus 5-öt ad 
vissza (három darab 1-es és két darab 2-es). 


result z count if(v.beginŐ ,v.end() ,bindznd(lesscints0 3); 


Ha egy adott elemhalmaz bármelyik elemének első előfordulását keressük, 
akkor a find first of algoritmust használjuk. Ennek első paramétere a vizsgá- 
landó, második paramétere a keresendő elemeket megadó iterátortartomány. 
Példánkban megkeressük az első egyes vagy hármas értékű elemet. Ehhez 
létrehozunk egy tömböt, amelyre a továbbiakban is hivatkozunk majd: 


int seguence[] — (1,3)8 





A find first of függvényt az alábbi módon hívjuk: 





Az algoritmus egy, a 2. pozícióra mutató iterátort ad vissza, amelynek értéke 
egy, és természetesen nem előzte meg sem egyes, sem hármas értékű elem. 

Eddig egyedi elemeket kerestünk. Léteznek azonban olyan algoritmusok 
is, amelyek szekvenciákat, vagyis egymás után sorfolytonosan következő ele- 
meket keresnek. Ilyen például a search algoritmus, amely egy adott szekven- 
cia előfordulását keresi. Elsőként a vizsgálandó tartományt kell átadnunk, 
másodikként a keresett szekvenciát tartalmazó iterátortartományt. Az alábbi 
példa az 1,3 szekvencia első előfordulására mutató iterátort adja vissza, 
amely esetünkben a 2. pozíciójú elemre mutat. 
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mese ee PVEZKÉKSEZEZZERÉSE SSRKÉSERÉZEtEK B tást 
Ha a szekvenciának nem az első, hanem az utolsó előfordu 

a hasonló paraméterlistájú find. end algoritmust érdem 

1.3 szekvencia utolsó előfordulását kapjuk meg, 


lását keressük, akkor 
es használnunk. Most az 
amely a 8. pozícióban van. 





Ha egyetlen elem többszöri ismétlődéséből álló szekvenciát keresünk, akkor a 
search-n algoritmust hívjuk. Ennek az algoritmusnak meg kell adnunk a 
vizsgálandó tartományt, a szekvencia hosszát és az ismétlődő elem értékét. 
Ez alkalommal a két darab hármasból álló szekvencia első előfordulását ke- 
ressük. Az algoritmus által visszaadott operátor az 5. pozícióra mutat, ahol 
először fordul elő két hármas. 


meeintiterator p3s - search! 


Ha két egyenlő szomszédos elem első előfordulását szeretnénk megkapni, ak- 
kor az adjacent find algoritmus a megfelelő választás. 


erfntlíterátor padj - adjacentfind(v.begínÖ,v.endőjp eme 





Példánkban az algoritmus az 5. pozíciójú elemre mutató iterátorral tért visz- 
sza, ahol az első dupla elem, nevezetesen két egymás után következő hármas 
található. 

Ha nem az egyenlőség számít, hanem más feltételünk van, kihasználhat- 
juk a paraméterként megadható művelet lehetőségét. Ha például olyan pá- 
rost keresünk, ahol az első kisebb, mint a második, akkor a less függvényob- 
jektumot adjuk meg: 


IEGHUJZE adjácent find(v.. begtKÖTVZENÁTIGTEGSZTNKES JT EN ATESNNETESE 


Az algoritmus a 2. pozícióban talált először ilyen elemeket, ahol az 1,3 szek- 
vencia van. köde! ; 

Végül nézzük meg, hogyan lehet megkeresni az összes hármas elem pozí- 
cióját. Egy lehetséges megoldást mutat az alábbi kódrészlet: 





Ki £3 tti be 
A fenti példát a find algoritmus helyére más keresési algoritmust fézgklés 


sítve könnyen általánosíthatjuk. 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 


Tartományok összehasonlítása 


Két tartomány egyezését az egual algoritmussal vizsgálhatjuk. Az egual első 
két paramétere az első tartományt adja meg, a harmadik argumentum a máso. 
dik tartomány kezdetét jelöli ki. Az algoritmus az azonos pozíciójú elemek 
egyenlőségét vizsgálja. Ha nem megfelelő a tárolt típus —— operátora (pointerek 
tárolása esetén ez általában így van), akkor egy negyedik, opcionális paramé. 
terként megadható egy elemenkénti összehasonlítást végző kétargumentumú 
predikátum. Az alábbi példában két vektort, v1-et és v2-t hasonlítjuk össze. 


egual(v1.begin() ,v1.end() ,v2.begin 0); za 


Ha a visszatérési érték igaz, a két tartomány elemenként egyenlő, ellenkező 
esetben nem. Mivel az algoritmus a második tartományt az első tartomány- 
nyal egyenlő hosszúságúnak tételezi fel, gondoskodnunk kell róla, hogy leg- 
alább annyi elem legyen a második tartományban, mint az elsőben, különben 
futásidejű hibát kapunk. 

Ha szeretnénk tudni, melyik az a legelső elem, ahol a két tartomány kü- 
lönbözik, akkor a mismatch algoritmust használjuk. Az algoritmus argumen- 
tumai megegyeznek az egual argumentumaival. A visszatérési érték egy 
iterátorpár: az első elem az első tartományban mutat az első eltérő elemre, a 
pár második tagja ugyanezt mutatja a második tartományban. Itt is figyel- 
nünk kell, hogy a második tartomány legalább olyan hosszú legyen, mint az 
első. Példánkban két, egészeket tartalmazó vektort hasonlítunk össze. 


sa 


ch) 






. Paircintóiterator,int iterators 7 : érné 
0 ——— pdiff - mismatch(v1.beginO) ,v1.end() ,v2.beginO ); 


Ha volt eltérés, akkor annak v1 vektorbeli pozícióját a pdiff.first kifejezés adja 
vissza, míg a v2 vektorbeli pozíciót a pdiff.second tárolja. Ha a két vektor meg- 
egyezik, akkor a tartományok határát jobb oldalról kijelölő iterátorokkal tér 
vissza. A párban megadandó típusok az adott tárolók iterátortípusai:; ha külön- 
böző tárolók elemeit hasonlítjuk össze, akkor ezek a típusok is különbözőek. 

Az eddigi két algoritmus vagy az —— operátort használta az egyes elemek 
összehasonlítására, vagy a megadott kétargumentumú predikátumot. Ha sze- 
retnénk elemenként ábécérend szerint összehasonlítani két tartományt, ak- 
kor a lexicographical compare algoritmus a megfelelő választás. Ez az algo- 
ritmus csak akkor tér vissza igaz értékkel, ha az elemenkénti ábécé szerinti 
rendezésben első tartomány előbb van (az ábécé szerint kisebb), mint a máso- 
dik. A lexicographical compare algoritmus az előző algoritmusokkal ellentét- 
ben két-két iterátorral jelöli ki az összehasonlítandó tartományokat. 

A lexicographical compare is a két tartomány elejéről indul, és egyenként 
összehasonlítja az azonos pozíciójú elemeket vagy az elemek c operátora 5e- 
gítségével, vagy a megadott predikátummal. 
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a Ha két azonos pozíciójú elem nem ekvivalens, aj 


a 2. kkor az ány 
kisebb, amelyik a kisebb elemet tartalmazza. bzs zagsáka 


. Ha mindegyik elem ekvivalens volt, és az e. 


övi gyik tartomány végére ér. 
tünk, akkor a rövidebb tartomány a kisebb. ány végére ér. 


, Ha mindkét tartomány egyszerre ért véget, és minden elem ekvivalens 
volt, akkor a két tartomány megegyezik. Mivel az első tartomány ilyen. 
kor nem kisebb a másodiknál, a visszatérési érték ekkor is hamis. — 


Nézzük meg, hogy az Andrea előbb van-e az ábécében, mint a Georgina! 


char str1(]J-"Andrea"; 

char str2[]-"Georgina" ; KATEGYN 

Texicographical. compare(str1, strlisizeof(str1) , 
str2isizeof(str2)); 





A fenti példában feltételeztük, hogy a sizeof(char) értéke 1. A fenti esetben a 
függvény igazzal tér vissza. Ha felcseréljük a két tartományt, akkor a vissza- 
térési érték hamis. Az "Abcde" összehasonlítása saját magával hamis ered- 
ményre vezet. Az "Abcde" és az "Abcdef" összehasonlítása esetén a lexicographi- 
cal compare algoritmus igazzal tér vissza. 


Módosító algoritmusok 


Az általános célú módosító algoritmusokat egy nagyobb példán szemléltetjük. 
Ezután különös hangsúlyt kapnak a törlést végző algoritmusok, amelyek ne- 
vükkel ellentétben nem végeznek törlést, csak bizonyos tárolók esetén segítik 
a tényleges törlést végző tagfüggvényeket. Végül az iterátortartományokon 
végzett másolást és cserét mutatjuk be. 


Általános célú módosító algoritmusok 


Az egyik leggyakrabban használt módosító algoritmus a 12.1.3. pontban már 
megismert for each algoritmus, amely minden egyes elemen végrehajtott egy 
műveletet. Ez a művelet nem feltétlenül változtatja az egyes elemeket, de 
megteheti, és ezért jelen tárgyalásban a módosító algoritmusok között említ- 
jük. A for each futásának eredménye két helyen jelenhet meg: az elemek mó- 
dosításán keresztül, illetve a visszaadott függvényobjektumban. Szükség le- 
het azonban olyan általános algoritmusra, amely ugyanúgy végrehajt egy 
műveletet az egyes elemeken, mint a for. each, de a kimenete egy másik tar- 
tomány, Erre szolgál a transform algoritmus. h 

A transform algoritmusnak két változata van. Az egyik egy i 6 
mány alapján a művelet eredményét egy másik iterátortartományba KG 
másik két iterátortartomány elemein lefuttatott művelet eredményét Hé 8 
egy harmadik tartományba. Természetesen a céltartományban nekün 58 
helyet foglalnunk az algoritmus eredményének, vagy beszúró iterátoroka 
kell használnunk. 


iterátortarto- 
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Ha egyetlen tartomány alapján állítjuk elő az algoritmus eredményét, 
akkor egyoperandusú műveletre van szükség. Példánkban egy egészeket tar. 


talmazó v1 vektor elemeinek kétszeresét beszúrjuk a vi 


3 vektor végére: 





A transform visszatérési értéke a céltartomány legutoljára generált eleme 
utáni pozícióra mutató iterátor, A transformnak megadhatjuk ugyanazt a két 
tartományt, ilyenkor a művelet eredménye felülírja a művelet argumentu- 
mát, Példánkban a vu! vektor elemeit kétszeresére növeljük. 





Ha két tartomány alapján állítjuk elő az eredményt, a transform számára meg- 
adott művelet két argumentumot vár, Példánkban összeadunk egy egészeket 
tartalmazó ul és v2 vektort, és az eredményt a vd vektor végére szúrjuk be. 








Feladat: Írjunk egy egyszerű statisztikai funkciókat megvalósító programot! A program a be- 
épített srand/rand függvényeket felhasználva generáljon egyenletes, illetve normális eloszlású 
valószínűségi változókat egy megadott íterátortartományba! Becsüljük meg egy íterátortarto- 
mányban lévő változók várható értékét és szórásnégyzetét, 


Ha egy adott iterátortartományba n darab számot szeretnénk generálni, ak- 
kor generate n algoritmust érdemes használnunk. Az algoritmus első para- 
métere az íterátortartomány kezdete, a második a generálandó elemek szá- 
ma, a harmadik egy argumentum nélküli művelet, amelynek visszatérési ér- 
téke a generált érték, amelyet a generate n beszúr az aktuális pozícióba. 

Elsőként tehát írunk egy függvényobjektumot, amely egyenletes eloszlás 
szerint álvéletlen számot generál 0 és 1 között.58 





5 Ehhez a C nyelvű rand függvényt használjuk, amely 0 és RAND MAX közötti álvéletlen 
számokat generál. Ehhez inicializálnuk kell az álvéletlenszám-generátort, amelyet az 
srand függvénnyel tehetünk meg. Ha ugyanazzal a számmal inicializáljuk a generátort, 


mindig ugyanazt a sorozatot kapjuk. Ezért §j vi u 
lis időt adjuk meg. pi az srand függvény paramétereként az aktuái 
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drei / Inicializáljuk a véletlenszám-generi: 
[dátum tgnedJttmetNŰL I; 





ver 
rt 


§ 
double operator O 





( té i 
// Generálunk egy véletlen számot 0 és 1 között 
Kéeöra randO / (double) RAND. MAX; z 8 


hi 


A C nyelvből örökölt függvények esetünkben a cstdlib, illetve a cmath, vala- 
mint a ctime állományokban találhatók. Ezek rendre az stdlib.h, math.h, il- 
letve a time.h állományokban található függvények. Ez a konvenció a többi 
megszokott C állományra alkalmazható. A random osztály konstruktorában 
inicializáljuk a véletlenszám-generátort az aktuális idővel. A () operátorban 
pedig minden egyes híváskor generálunk egy véletlen számot, amelyet 0 és 1 
közé normálunk. 

A második lépés a normális (Gauss) eloszlású változók generálása, ame- 
lyet egyenletes eloszlású változók átlagából képezünk. 


class random gaussian 
( 
random generator; 
unsigned int n; 
double variance; 
double expectedvalue; 
public: 
random gaussian(double expectedvalue - 0, double variance - 4 At 
unsigned int n - 1000): 
expectedvalue (expectedvalue) , variance(variance) ,n(n) £) 


double operator O 

( 
double sum — 0; 
for(unsigned int i - Ll;i cz n;ítt) 
( 


Sum 4z generator(); 
sum -z n/2; 
Sum /z sgrt(n/12.0); 
Sum - sumtsgrt(variance) 4 expectedvalue; 


return sum; 


e kest szórásnégyzet, valamint az, 
A konstruktorban megadható a várható érték és a szórásne gyzet, vala 


hogy hány véletlen szám összeadásával generáljon mintát. 
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A fenti függvényobjektumokkal meghívjuk a generate n algoritmust. Elő. 
ször 10 egyenletes eloszlású álvéletlen számot generálunk: 


generate. n(back. inserter (nums) , 10, random ) ; 
Majd 1000 normális eloszlású mintát 0 várható értékkel és egységnyi szórással: 
generate. n(back.inserter(nums) , 1000 , random gaussian()); 


Következőként a várható értéket számoljuk ki egy függvényobjektummal, ami 
tulajdonképpen átlagolást jelent: 


class expected value 
í 
double sum; 
double counter; 
public: 
expected. value() : sum(0) , counter(0) (3 
void operator() (const double value) ísum 4- value; countertá;) 
double get (return sum/counter;) 
u 


Természetesen a szórásnégyzetet is függvényobjektum becsli:"9 


class variance 
:t 
double expectedvalue; 
double sum; 
double counter; 
public: 
variance(double expectedvalue-0) : expectedvalue (expectedvalue) , 
sum(0) , counter(0) (3 
void operator() (const double value) 


double diff-expectedvalue-value; 
sumázdiffrdiff; 
counter44; 

ti 

double getO 

ú3 


assert(counter21) ; 
return sum/(counter-1); // tapasztalati szórásnégyzet 


B 





"s Ha a várható értéket nem szeretnénk kiszámolni, akkor a tapasztalati szórásnégyzetet 


N xy 





az alábbi képlettel számíthatjuk: S, - Így ha függvényobjektumban 

s ENÁT,  á 
írjuk meg a várható érték és a szórásnégyzet számi sát, akkor elég egyszer végigiterál- 
nunk az adatokon, ami sok esetben jelentős sebességnövekedést okozhat. 
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Végül nincs más dolgunk, mint a for. each algoritmussal kiszámolni a szórás- 
négyzetet és a várható értéket: 





Ezzel megoldottuk a feladatot. Megjegyezzük még, hogy a generáláshoz hasz- 
nálhatjuk a generate függvényt, ahol az iterátortartománynak nemcsak az 
elejét, hanem a végét is megadjuk, így a függvény annyi elemet generál, 
amennyi az iterátortartomány méretéből következik. Ettől eltekintve haszná- 
lata megegyezik a bemutatott generate n algoritmuséval. 

Ha csak egy adott értékkel szeretnénk feltölteni egy iterátortartományt, 
akkor a fill és a fill n algoritmusokat használhatjuk. Ezek abban különböznek 
a generate és a generate n algoritmusoktól, hogy nem egy műveletet, hanem 
egy értéket várnak. Az alábbi példa feltölt egy üres vektort öt darab nullával. 


7 FiT-n(back inserter(v1),5,OJg 
Törlés 


Az eddigiek során láttuk az iterátoron keresztüli adatelérés számos előnyét, 
amely abból származott, hogy egy általános adatszerkezetből álló tartomá- 
nyon végeztünk műveletet, és a belső felépítést figyelmen kívül hagyhattuk. 
Az általánosítás ugyanakkor elfed bizonyos részleteket, amelyekre olykor 
szükségünk lenne. Erre jellemző példa az elemek törlése. Itt főként két prob- 
léma adódik. 





. Az első probléma a törlés végrehajtása, amit az egyes tárolók tag- 
függvényeivel végezhetünk. Ezeket a funkciókat az iterátortartomá- 
nyon keresztül nem érhetjük el. 


s A második probléma a tároló belső felépítésének figyelembevételéhez 
kapcsolódik. Ha láncolt listából törlünk, mindössze néhány pointert 
kell állítanunk. Ha egy degue vagy egy vector tárolóról van szó, akkor 
el kell léptetnünk a törlendő elem utáni elemeket. Ezek a különbsé- 
gek az iterátortartományon keresztül nem látszanak. 


Vagyis biztosan nem készíthető olyan algoritmus, amely valóban töröl egy ite- 
rátortartományból. A legtöbb, amit egy törlőalgoritmus tehet értünk, hogy az 
iterátortartományból a törlendő elemek helyére belépteti az utánuk követke- 
ző elemeket, és megadja az érvényes elemek új, logikai végét. Ez a megoldás 
értelemszerűen csak olyan tárolónál hatékony, amely folytonos memóriaterü- 
leten tárolja az elemeit, mint a már említett degue és vector tároló. Ennek az 
algoritmusnak a neve remove. Bemeneti paramétere egy iterátortartomány és 
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egy érték, amellyel egyenlő értékeket el kell távolítani a megadott iterátortar. 
tományból. Ezért az elemeknek érvényes —— operátorral kell rendelkezniük, 
Az algoritmus visszatérési értéke az eltávolított adatok nélküli iterátortarto. 
mány végpozíciója, vagyis az utolsó el nem távolítandó elem utáni pozíció, Az 
alábbi példák kiindulásaként tegyük fel, hogy egy nums nevű egész értékű 
vektor az alábbi elemeket tartalmazza: 


IZZAGSISZTKÉBI 





A vektorra meghívjuk a remove algoritmust: 
remove(nums . begin , nums.end() , 3); 


Ekkor a vektor az alábbi elemeket tartalmazza: 





FONAL ES SSE BZ 





A remove algoritmus visszatérési értéke az utolsó előtti pozícióban lévő 5-re 
mutat jelezvén, hogy az első 6-osig érvényes az új, eltávolított elemek nélküli 
tartomány, de mivel iterátort nem törölhet, az eredeti, nagyobb iterátortarto- 
mány vége érvénytelen maradékadatot tartalmaz. 

Egy nums nevű vektorból az alábbi módon törölhetjük az összes elemet, 
amelynek az értéke három: 





.. nums.ei 





(nums.beginO , nums.end() 3), nums.endO JT 





Ismét hangsúlyozzuk, hogy a remove algoritmus a nevével ellentétben nem 
töröl (nem is tudna!). A visszatérési értékként kapott iterátor éppen az első 
törlendő elemre mutat. Így felhasználhatjuk a vector iterátortartományt váró 
erase tagfüggvényét, amely a példában látható módon felparaméterezve tény- 
legesen törli a vektor végére rendezett elemeket. 

A fenti kódrészlet eredményeként az összes három értékű elem valóban 
törlődött a vektorból: 





Egyben magyarázatot kaptunk arra is, miért nincs a vector, illetve a degue 
tárolónak érték szerinti törlést végző paramétere: ezt a műveletet ugyanis a 
remove algoritmus segítségével hajtjuk végre. Más tárolók tagfüggvényekkel 
támogatják az érték szerinti törlést. A list tartalmaz remove tagfüggvényt, az 


asszociatív tárolók esetén az erase függvény túlterhelései közül az egyik biz- 
tosítja a kulcs szerinti törlést. 





12.3. Szabványos algoritmusok" 
zzz s tt Ten szen aztán szant 


A remove algoritmusnak további változatai is vannak. A remove if az érték 
helyett egy egyargumentumú predikátumot vár, melynek igaz visszatérési értéke 
adja meg a törlendő elemeket. Ilyenkor természetesen nincs szükségünk érvé- 
nyes —— operátorra. Esetünkben az összes hárommal osztható elemet fogjuk tö- 
rőlni. Ehhez szükségünk van egy olyan egyargumentumú predikátumra, amely 
akkor tér vissza igaz értékkel, ha az adott egész elem osztható hárommal: 


bool divisible by. threeCint element) 


return elemen tX 3 — 0; 
ti 





A törlésben ezúttal csak a remove. if paraméterezése jelenti a különbséget: 


nums . erase (remove. if(nums .beginO , nums.endC) ,divisible by. three) , 
nums .endC)) ; 


Mindkét algoritmusnak létezik egy copy utótagú változata is. Ezek nem az 
eredeti tartományt módosítják, hanem egy új tartományba másolják a kime- 
netüket, természetesen a törlendő elemek nélkül. Vagyis itt nem kell külön 
törölni a kimeneti tartomány érvénytelen részét, mert azt egyszerűen nem 
másolja le az algoritmus. Az alábbiakban mutatunk egy példát a remove copy 
algoritmusra, a remove if copy algoritmus csak abban tér el, hogy egy érték 
helyett predikátumot vár. 


vectorcints: nums2; B 
remove. copy(nums . begin() , nums.end() , back. inserter(nums2) , 3) ; 


A nums2 tartalma az alábbi: 
12456 


A nums tartalma természetesen az eredeti szekvencia, a remove. copy a be- 
meneti iterátortartományt nem módosítja. § 

A remove algoritmushoz nagyon hasonlóan működik a unigue algoritmus- 
család. A különbség, hogy ezek az algoritmusok nem egy értékkel vagy predi- 
kátummal meghatározott elemet távolítanak el, hanem több egymás után kö- 
vetkező egyenlő elem közül csak az egyiket hagyják meg. Az egyenlőség meg- 
állapítása vagy az elem —— operátora segítségével történik, vagy egy OPcIon4- 
lisan megadható kétargumentumú predikátummal. A 

Ezúttal az alábbi elemeket tartalmazó nums nevű vektorból in: 


dulunk ki: 
1,3,3,3,2,3,4,5,6 
Erre a vektorra lefuttatjuk a unigue algoritmust: 


nums .erase(unigue(nums . begin) ,nums.endO ) , nums.endO ds 
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Ekkor az eredményként előálló nums vektor: 
132344-6 


A unigue copy esetén az eredmény egy másik iterátortartományban keletke. 
zik, a remove. copy algoritmushoz hasonlóan kizárólag érvényes adatokkal, 
A unigue. copy algoritmusnak is megadhatunk egy opcionális kétargumentu. 
mú, összehasonlítást végző predikátumot. 

A példán jól látható, hogy nevével ellentétben, amely egyedit jelent, nem 
távolítja el az összes többszörösen előforduló elemet csak egyet hagyva közü. 
lük, hanem csak a soron következő elemek esetén működik így. Ha azt sze- 
retnénk, hogy minden elem csak egyszer szerepeljen, akkor rendezni kell a 
tárolót, és úgy kell lefuttatnunk a unigue algoritmust. A rendezőalgoritmuso- 
kat a 12. Sorrendváltoztató algoritmusok fejezet tárgyalja, jelen esetben a 
12.1.3. Algoritmusok fejezet Rendezett vektor részéből már jól ismert sort al- 
goritmust használjuk. 





sort(nums . begin) , nums . end() ) ; 
nums ,erase(unigue(nums begin ,nums , endŐ) ) , nums ,end() ; 


Ekkor egy elem tényleg csak egyszer fog szerepelni, de az elemek sorrendje 
megváltozott. A nums vektor tartalma az algoritmusok lefutása után az alábbi: 


423456 


A unigue algoritmust is vector és degue tárolókra érdemes használnunk. A list 
tároló esetén a unigue nevű tagfüggvény sokkal hatékonyabb lehet. Jóllehet a 
unigue algoritmusokat asszociatív tárolókra sorrendváltoztató tulajdonságuk 
miatt egyáltalán nem használhatjuk, nem is lenne értelme, hiszen ott az 
egyediséget tárolóválasztással, vagy az egyediséget biztosító tárolóba való 
másolással garantálhatjuk. 


Másolás és csere 


A copy algoritmust már ismerjük a 12.1.3. részből, Ahogy számos algoritmus- 
nak, a copynak is több változata van. A copy. backward eredménye ugyanaz, 
mint a copy algoritmusé, a különbség csak annyi, hogy a másolás nem az első 
elemmel kezdődik, hanem az utolsóval, és nem előre, hanem hátra lépteti a 
céltartomány iterátorát. Ennek következtében a céltartománynak kivételesen 
nem az elejét, hanem a végét kell megadnunk. Ez a szokásos módon történik: 
az algoritmus az utolsó elem utáni pozíciót várja. Példaként másoljuk át a 
nums nevű vektor elemeit egy nums?2 nevű vektorba visszafelé: 
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Fontos, hogy a céltartománynak helyet foglaljunk. Itt nem használhatjuk a 
szokásos beszúrókat, hiszen azok nem támogatják a — — operátorokat. 

Ha az elemeket fordított sorrendben szeretnénk átmásolni, akkor a 
reverse. copy algoritmust használhatjuk, amely némileg hatékonyabb lehet, 
mint ha a copy algoritmus hívjuk fordítóiterátorokkal. Mivel nincs copy if al- 
goritmus, ha valamilyen szűrési feltételt is szeretnénk figyelembe venni a 
másolás során, a fent tárgyalt remove copy algoritmust használhatjuk. Ha az 
elemek értékét is változatni szeretnénk, akkor a 12.3.3. pontban ismertetett 
transform, illetve replace copy algoritmus lehet megfelelő. 

A replace copy a replace algoritmus egyik változata, amely az összes, a 
megadott értékű elemmel egyenlő elemet kicserél egy új értékre. Az alábbi 
példa az összes 3 értékű elemet kicseréli 7-re. 


— replace(núms.beginO , nums.e 





A replace az — operátort használja a cserélendő elemek megkeresésére. Ha fel- 
tételként szeretnénk meghatározni a cserélendő elemeket, azt a replace if 
függvény segítségével tehetjük meg, amely a cserélendő érték helyett egy egy- 
argumentumú predikátumot vár, amelynek igaz értéke jelöli ki a cserélendő 
elemeket. Ha nem szeretnénk módosítani a bemeneti iterátortartományt, akkor 
a replace copy függvényt használjuk. Az alábbi példa kicseréli az összes 7-es ér- 
tékű elemet 3-ra, és beszúrja a nums2 vektor végére. 


replace copy(nums . begin) , nums . end) , back inserter(nums2) , 7, 3); 


Ha nem értékkel, hanem művelettel szeretnénk kijelölni a cserélendő eleme- 
ket, akkor a replace copy if függvényt használhatjuk. 


12.3.4. Sorrendváltoztató algoritmusok 


A sorrendváltoztató algoritmusok közül a reverse algoritmust — amelynek lé- 
tezik egy reverse copy változata is, amely az eredményt egy másik iterátortar- 
tományban adja vissza — már ismerjük a 12.1.3. részből. A továbbiakban rö- 
viden bemutatjuk a permutáló algoritmusokat, majd a rendező algoritmuso- 
kat. Végül a kupacalgoritmusokat ismertetjük röviden. 


Általános célú sorrendváltoztató algoritmusok 


Ha elő szeretnénk állítani egy számsorozat összes permutációját, akkor két 
algoritmus áll rendelkezésünkre: a next permutation, illetve a Drev-peritt- 
tation. Mindkét algoritmus egy permutációt állít elő: az elemenkénti ábécé- 
rend szerinti eggyel nagyobb, illetve kisebb permutációt. Ez azt jelenti, hogy- 
ha képzeletben előállítanánk az összes permutációt, és az alapértelmezett c 
Operátor vagy az opcionálisan megadható rendezőművelet szerint elemenkén- 
ti összehasonlítással ábécérendbe rendeznénk őket, az algoritmus a bi jei 
Permutációt követő, illetve megelőző permutációt adja vissza. Így a két algo- 
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ritmus gyakorlatilag inverze egymásnak. A képzeletbeli ábécérendben az első 
permutációt az elemek növekvő sora alkotja, illetve az utolsó permutációt az 
elemek csökkenő sorrendje. Vagyis a next permutation csak az utolsó permu. 
tációig képes visszaadni a következő elemet. Ezt a visszatérési értékével jelzi: 
ha létezik nagyobb permutáció, akkor igazzal tér vissza, ellenkező esetben 
hamissal. Amikor hamissal tér vissza, akkor az iterátortartományt növekvő 
sorrendbe rendezte. Vizsgáljuk meg az alábbi példát! 





Ekkor az eredmény: 





Jól látható, hogy ha a növekvő sorrendbe rendezett permutációból indulunk 
ki (abc), akkor a next permutation előállítja az összes permutációt ábécé sze- 
rinti növekvő sorrendben. Említettük, hogy a fordított sorrendbe rendezett 
permutáció (cba) az utolsó az ábécé szerinti sorrendbe állításnál, vagyis ami- 
kor azt visszaadja a függvény, akkor a következő hívás hamissal tér vissza. 
A ciklus után a tömb növekvő sorrendbe rendezett (abc), de ezt már nem írat- 
juk ki. A prev permutation a csökkenő sorrendbe rendezett permutációból 
(cba) indítva jut el a növekvően rendezett permutációig (abc). Hasonlóan a 
next permutation algoritmushoz, ha nincs további permutáció, akkor hamis- 
sal tér vissza. Jóllehet a példában az ábécérend miatt betűkkel illusztráltuk a 
függvényeket, más típusú adatok permutációjára talán gyakrabban szükség 
van, ekkor is használhatjuk a két algoritmust. 

Ha nem szeretnénk az összes permutációt generálni, csak egy véletlen 


sorrendet szeretnénk előállítani, akkor a random shuffle algoritmust hasz- 
HÁlhajjuk, 


7 randoncshuffleCnums. begin ,iums.endOJa 


—  numstiterator ít3-nums.beginO 42; 








12.3. Szabványos algorítmusok" 
zza Ka sze B sdságozszroró B 


Ez a beépített véletlenszám-generátort használja, de ha szeretnénk, opcioná- 
lis argumentumként megadhatunk saját véletlenszám-generátort is, amely- 
nek 0 és az argumentumként kapott maximum elemnél eggyel kisebb szám 
között kell egy véletlen számot generálnia. 

Az elemeket forgathatjuk is. Ilyenkor a hátul kiléptetett elemeket az 
iterátortartomány elejére szúrjuk be. A függvénynek nemcsak az iterátortar- 
tomány kezdetét és végét kell megadni, hanem e kettő között egy harmadik 
iterátort is. Az algoritmus úgy hajtja végre a forgatást, hogy a középső 
iterátor által mutatott elemet és az összes tőle jobbra található elemet lépteti, 
Ez tulajdonképpen azt jelenti, hogy a középső iterátortól balra levő elemeket 
az iterátortartomány végére, a többit az iterátortartomány elejére másoljuk. 
Tekintsük meg az alábbi példát: 













(123 .AGSIE 
Z nts nums (ar, arssizeof(ar), 
ctorcints::iterator num: 





.  rotate(nums.beginO ,it3,nums.endOdg 
. copy(nums.begin() , nums . end() ,ostream iteratorcints(cout, " 


A program kimenete az alábbi: 

ER 42 By BEEE TAO TERRA] 
Ha nem szeretnénk a forgatással felülírni az iterátortartományt, akkor a 
rotate copy algoritmust használjuk. 

Rendezés 
A rendezés az egyik leggyakrabban használt művelet, ezért az STL számos 
lehetőséget kínál ennek végrehajtására. Emlékeztetőül újra felsoroljuk az 
STL rendezőalgoritmusait: 

e partition 

9. stable partition 

e  nth element 

e partial sort 

e sort 

e stable sort 
Mindegyik algoritmusnak van egy olyan változata is, amelynek az összeha- 


sonlító műveletet is megadhatjuk. Az egyes rendezőalgoritmusokat feladaton 
keresztül mutatjuk be. 
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Feladat: Egy tanulmányi verseny résztvevőinek nevét és pontszámát vektorban tároljuk, ahová 
a munka beadásának sorrendjében tesszük be az elemeket. Számoljuk ki a következő adatokat: 


Keressük meg csak az első három helyezettet sorrendben, hiszen azoknak a nevére kelt 
kiállítani az okleveleket! 


Keressük meg csak a negyedik helyezettet, mert neki jár a különdíj! 


Különítsük el azokat, akik 0 vagy 1 pontot veszítettek, ugyanis ezek nevét külön felol- 
vassák! 


Rendezzük a résztvevőket névsor szerint, azon belül pedig pontszám szerint! Az egysze- 
rűség kedvéért tekintsünk el az előnév-utónév szétválasztásától! 





A fentiek nem egymásra épülő, hanem külön megoldandó feladatok, így min- 
den pont megoldásakor az eredeti vektorból indulunk ki, 


Megoldás 


A résztvevőket a Participant osztály zárja egységbe, a pontszámmal fordított 
sorrendbe rendező £ operátora van, illetve értelmezett rá a kiírató c£ operátor, 


class Participant 

(8 
friend ostream $ operator cc (ostream£g, const Participanté); 
unsigned char points; 

public: 
string name; 


Particípant(string name, 


unsigned char points) :name(name)( setPoints(points);) 
void setPoints(unsígned char points) 


if(pointscz100) 
this-spointszpoints; 
else 


; throw out of. range("Points must be between 0 and 100"); 


váj operator c (const Participant§ right)const 


return points 2 right.points; 
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Ezek után létrehozzuk a vektort, és beleteszünk néhány tesztadatot. 
vectorcParticipant: participants; 


participants .push. back(Participant("Tommy Third" ,98)); 
participants.push. back(Participant("Freddy First",100)); 
participants .push. back(Participant("Ted Third" ,98)); 
participants .push. back(Participant("Sam Second" ,99)); 
participants.push. back(Participant("Tim Third" ,98)); 


Vagyis a résztvevők az alábbi sorrendben adták be a munkájukat az alábbi 
pontszámmal: 


Name: Tommy Third Points: 98 
Name: Freddy First Points: 100 
Name: Ted Third Points: 98 
Name: Sam Second Points: 99 
Name: Tim Third Points: 98 


Ha csak az első három helyezettet szeretnénk megkeresni, első gondolatunk 
partial sort algoritmus lehetne, amely egy megadott iterátor előtti pozícióig 
rendezi a tartományt. A partial sort használatát az alábbi példa mutatja: 


partial. sort(participants.begin() , 
participants.begin() 3, participants.endO ) ; 


Az első paraméter a tartomány kezdete, az utolsó a tartomány vége. A közép- 
ső iterátor azt az elemet adja meg, amely előtti pozícióig rendezni kell a tar- 
tományt, ez jelen esetben a negyedik eleme, és a vektor kezdetétől hármat 
kell léptetnünk, hogy a negyedik elemhez jussunk. Az eredmény a következő: 


Name: Freddy First Points: 100 
Name: Sam Second Points: 99 
Name: Tommy Third Points: 98 
Name: Ted Third Points: 98 
Name: Tim Third Points: 98 


Vagyis a részleges rendezés a tesztadatok fényében jó megoldásnak tűnik. Vi- 
szont, ha történetesen a munkák más sorrendben érkeznek be, és az első négy 
helyre vagyunk kíváncsiak, akkor meglepő eredményt kapunk: 


Beadás sorrendje: 

Name: Tommy Third Points: 98 
Name: Freddy First Points: 100 
Name: Ted Third Points: 98 
Name: Tím Third Points: 98 
Name: Sam Second Points: 99 
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A beadás ideje alapján a harmadik hely jól láthatóan Tommynak járna, de 
Tim megelőzte. Ted, aki a negyedik hely jogos várományosa lenne, az ötödik 
helyen végez. 

A probléma abban rejlik, hogy a partial sort nem stabil. Ez azt jelenti, 
hogy nem garantálja, hogy az ekvivalens elemek egymáshoz viszonyított sor- 
rendje nem változik. Így a beadás sorrendjét nem mindig tartja be a rendező. 
algoritmus, mint azt a példa is illusztrálta. A partial sort algoritmusnak 
nincs stabil változata, ezért kénytelenek vagyunk a stable sort algoritmust 
használni, amelyet később mutatunk be. 

Térjünk rá a második alfeladatra, és számoljuk ki a negyedik helyezettet. 
Ezt a feladatot teljesen függetlennek tekintjük az előzőtől. A negyedik helye- 
zett kiszámolásához jónak tűnhet az nth element függvény. Ez az algoritmus 
csak a megadott, n-edik elemet rendezi. Ezen elem előtt csak nála kisebb 
vagy egyenlő, utána nála nagyobb vagy egyenlő elemek találhatók. 





Az algoritmus első és utolsó paraméterei a tartomány határait jelölik ki, a kö- 
zépső paraméter az n-edik elem pozícióját adja meg. Az eredmény az alábbi: 





A fentiekben az eredmény teljes rendezés, de ez nem szükségszerű. Az ered- 
mény helyes, ugyanakkor, ha az előbbi tapasztalatainkból okulva áttanulmá- 
nyozzuk a szabványt, látjuk, hogy nem kívánja meg, hogy az algoritmus sta- 
bil legyen. Ezért ismét a stable sort algoritmusra kell hagyatkoznunk. 

A reményvesztett olvasót szeretnénk megnyugtatni, hogy a 99 és 100 pon- 
tosok kiírása viszont elsőre sikerülni fog. Erre a partition algoritmus egyik 
változatát fogjuk használni, amely egy megadott feltétel alapján két részre 
osztja a tartományt: az első részébe azokat az elemeket rendezi, amelyekre 
igaz a feltétel, a maradék részbe pedig azokat, amelyekre nem. Visszatérési 
értéke az a pozíció, ahol sorban az utolsó olyan elem található, amely megfelel 
a feltételnek. A partitionnek van egy stabil változata is, a stable partition. 

Ehhez elsőként írnunk kell egy feltételműveletet: 
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red Third Points: 98 
e: Tim Third Points: 98 


Ha csak a kiválasztott részre vagyunk kíváncsiak, akkor a stable partition 


visszatérési értékére támaszkodhatunk, amelyet előzőleg a separatePos válto- 
zóban tároltunk: 


y(participants.beginÖ , SE FÖL hét LETERE 
[odás ; kögbarátákos dstrenuttasatanatantislkárttstéáut MAJ 





Korábbi problémáink megoldásaként hívjuk meg a stabil stable sort algorit- 
must, amely rendez egy iterátortartományt. A meghívása nem jelent különö- 
sebb nehézséget: 


[7 §tablessort(participants.beginO ,participants.endőJi 


Az eredményből pedig az első feladatok megoldásai adódnak, és láttuk, hogy 
ezek a feladatok gyorsabb STL algoritmusokkal nem oldhatók meg, mert a 
gyors algoritmusok nem stabilak. 


Útmutató: Ha fontos az ekvivalens elemek egymáshoz viszonyított sorrendje, akkor kizárólag [BA 


a stable partition vagy a stable. sort algoritmust használjuk! 
22 partition vagy a stable. sort algoritmust használjuk eme. 
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Name: Freddy First Points: 100 
Name: Sam Second Points: 99 
Name: Tommy Third Points: 98 
Name: Ted Third Points: 98 
Name; Tim Third Points: 98 





Ha a faliújságra szeretnénk kirakni a név és azon belül pontszám sz 
rendezett verziót, amelynél nem fontos a sorrend, akkor nincs szükségünk 
stabil rendezésre. Ehhez a már ismert sort algoritmust fogjuk meghívni, Itt 
nincs értelme stabil algoritmust használni. Most azonban nem a £ operátort, 
hanem egy statikus függvényt használunk fel: 


class Participant 


static bool sortByNameThenByPoints (const Participant§ left, 
const Participant$ right) 


if(Cleft.name-—right.name) // Ha név nem tudja eldönteni 
JEGHÁDA left.points 2 right.points; // Fordított sorrend 
else 

return left.namexright.name; // A név alapján rendez 





Így már es 


ak meg kell hívnunk a rendezőalgoritmust a tartománnyal és a 
művelett 





sort(participants begin) , 
participants,end() ,Participant: : sortByNameThengypoints) ; 


Ezzel egy példán keresztül bemutattuk az összes szabványos rendezőaálgorit- 
mus használatát. Jól látható, hogy az algoritmusok paraméterezése nagyon 
hasonló, viszont a célnak legmegfelelőbb algoritmus kiválasztása már több 
körültekintést igényel, Az alábbiakban ehhez próbálunk segítséget nyújtani. 

! A hatékonyság miatt a rendezőalgoritmusok a partition és a stable. par- 
títion kivételével véletlen hozzá ű iterátort várnak. Ez nem olyan nagy 
érvágás, hiszen az asszociatív tárolók amúgy is rendezik magukat, viszont lis- 
tát nem tudunk rendezni, Bzért a list rendelkezésre bocsát egy sort tagfügg- 
vényt, amely ráadásul stabil is. Vagyis, ha betartjuk azt az alapszabályt, hogy 
az ugyanolyan nevű tagfüggvényeket előnyben részesítjük az algoritmusokkal 
szemben, könnyen megoldhatjuk a problémát, A vector és degue, string típusú 
tárolókra és C típusú tömbökre pedig használhatjuk a fenti alzoritaracíták 
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Útmutató: 
— Ha egy lista összes elemét szeretnénk rendezni, használjuk a sort tagfüggvényét! 


— Ha vector és degue, string típusú tárolókat és C típusú tömböket szeretnénk teljesen 
éjdemt: éSiazekYÍVAlGPSS Elemek AH MSSOKEnd JTK megtartása nem követelmény, 
használjuk a sort algoritmust! ő 


— Ha vector és degue, string típusú tárolóknak és C típusú tömböknek szeretnénk az első 
valahány elemét megtudni a megfelelő sorrendben, és az ekvivalens elemek relatív sor- 
rendjének megtartása nem követelmény, akkor válasszuk a partial sort algoritmust! Ha 
a sorrend nem számít, akkor az nth element lehet a jó választás. 


— Ha szeretnénk egy tartományt egy adott kritérium alapján kettéválasztani, és a tárolónk 
list, vector, degue, string vagy C típusú tömb, akkor a partition vagy a stable partition 
a megfelelő választás. 





Az általános bemutatás után térjünk rá az egyes algoritmusok gyorsaságára! 
Ha nem szeretnénk belemerülni a részletekbe, azt mondhatjuk, hogy az algo- 
ritmusok a fejezet elején felsorolt listában gyorsaság szerinti sorrendben sze- 
repelnek. Ez természetesen nem általánosan érvényes, hiszen a partial sort 
akkor gyorsabb a sortnál, ha beérjük egy jóval kisebb tartomány rendezésé- 
vel, mint az egész tároló. Ugyanakkor a jellemző felhasználás esetén nagy va- 
lószínűséggel ez a helyes sorrend. 

Az STL nem ad egyértelmű előírást arra, hogy milyen algoritmussal kell 
implementálni az egyes rendezéseket, csak a komplexitást adja meg (ezt rész- 
letesen a 12.4.4. A tárolók műveleteinek összehasonlítása fejezet tárgyalja). A 
rendezés esetén ezek a konstansok kulcsfontosságúak, például a kedvező 
konstansok miatt a gyorsrendezés (guicksort) átlagosan jobb futási időt mu- 
tat, mint más kedvezőbb komplexitású rendezőalgoritmusok. E könyv témá- 
ján kívül esik az egyes algoritmusok bemutatása, ezt az Olvasó kimerítő rész- 
letességgel megtalálja a [19] irodalomban. 

A sort algoritmus eredetileg a gyorsrendezésre? épült. Ezt a legtöbb imp- 
lementációban egy optimalizáltabb algoritmus?! váltja fel, amely a gyorsren- 
dezést próbálja még hatékonyabbá tenni. Az egyes implementációk a kedve- 
zőtlen eseteket próbálják felismerni és más stratégiát használni helyette. 





" A gyorsrendezés átlagosan O(nlogn) komplexitású, viszont legrosszabb esetben 0(n?). 
A komplexitást a 12.4.4. A tárolók műveleteinek összehasonlítása fejezetben mutatjuk be. 

A Dinkumware és az SGI STL először gyorsrendezéssel próbálkozik, ha a felosztás ked- 
vezőtlenné válik, akkor kupacrendezést használ, kis elemszám esetén pedig beszúrásos 
rendezést. Mivel az algoritmus az ,oszd meg és uralkodj" elvet használja, ezeket a mód- 
rvallumokra is váltogathatja. Ez tulajdon- 
sort algoritmusra épül, amelyet végül 
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szereket egy keresésen belül az egyes részintei 
képpen az úgynevezett introsort vagy introspective 
egy beszúrásos rendezés egészít ki. 
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A stable sort algoritmus eredetileg az összefésülő rendezésen (mergesort) 
alapul. Ezt a jelenlegi Dinkumware és az SGI implementációk is követik.92 

A partial sort eredetileg kupacrendezést (heapsort) használt. Ez minden 
körülmények között O(nlogn) komplexitású. Ez az algoritmus nem helyben, 
az adott iterátortartományban rendez, hanem saját adatstruktúrát épít fel, 
amelyet a következő fejezet tárgyal. 


Kupacalgoritmusok 


Bináris kupacnak (binary heap) egy speciális adatszerkezetet nevezünk. Főként 
rendezésre és prioritásos sorok (12.4.1. pont) megvalósítására használják. Első 
közelítésben tekintsünk meg egy bináris fát, amelyre igazak az alábbi feltételek: 


e A bináris fában minden csomópontnak két gyermeke van, kivéve a 
legalsó szinten, ahol balról jobbra csak egy bizonyos pontig vannak le- 
velek, tovább viszont nincsenek. Az ilyen fát teljes bináris fának 
(complete binary tree) nevezzük. 


e — A szülő mindig nagyobb vagy egyenlő, mint a gyermekei.93 
6 
b 

naja 

29. ábra. Bináris fa, amelynél a legalsó szint vége nincs teljesen kitöltve 


A fenti feltételek miatt a fa tömbként is ábrázolható. Az illusztráció kedvéért 
az ábrán a fában megszokott éleket is feltüntettük. Ezt az adatszerkezetet 
nevezzük kupacnak. 


ÉGETT 
(el4]5]11]12[83] 
Se 


30. ábra. Kupac 


Jól látható, hogyha a tömböt 0-tól indexeljük, akkor az i. elem első gyermeke 
a Zi31, a második gyermeke a 2i-42 pozícióban található. Így már érthető az 
első feltétel a fa betöltöttségét illetően: ha középen , lyukak" lennének a fá- 


ban, akkor nem lehetne ilyen egyszerűen kiszámolni a gyermekek pozícióját. 
A gyermek szülőjét az 





"2 Ha van elég memória, ez az algoritmus O(nlogn) komplexitású, egyébként komplexitása 
O(nlog(n) log(n)). A Dinkumware STL kis elemszám esetén öeszítéksok rendezést 
Ex szséássős máséslet TELE ál. Az SGI implementáció összefésülő rendezést használ. 
la a szű vagy egyenlő, mint a gyermekei, az i pacstruktúra, de az 
STL jelenleg nem ezt támogatja. ESZO 6 relé seg 
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e; 

2] 

képlettel számolhatjuk, vagyis egyet le kell vonnunk az indexből, el kell osz- 
tanunk kettővel, és az eredmény egész részét kell vennünk. A fenti összefüg- 
gések alapján gyorsan kiszámolhatjuk a szülő, illetve a gyermekek pozícióját. 
Ezt a lehetőséget nem tudnánk kiaknázni, ha egyenként lépegetnénk a ki- 
számolt pozícióba. Érthető tehát, hogy a kupacalgoritmusok véletlen hozzáfé- 
résű iterátort várnak. 

A kupacból általában a legnagyobb elemet vesszük ki, majd ismét rendez- 
zük a kupacot. Kupac létrehozásához szükségünk van a kupacba rendezendő 
adatokat tartalmazó, véletlen hozzáférésű iterátorokkal megadott tartományra, 
illetve a make. heap algoritmusra. Ez az algoritmus kupaccá alakítja a meg- 
adott tartományt. Ezután a push heap függvénnyel tudunk új elemet hozzáad- 
ni. A hozzáadandó elemet nem külön argumentumként adjuk meg, hanem az 
iterátortartomány végére kell helyeznünk. A push heap feladata tehát az, hogy 
az iterátortartomány legutolsó elemét a többi elem által alkotott kupacban a 
megfelelő helyre tegye. A pop. heap algoritmus a legnagyobb elemet a megadott 
iterátortartomány végére teszi, és a maradék elemeket kupaccá rendezi. 

Tételezzük fel, hogy egy vektor az alábbi számsorozatot tartalmazza: 


84.542 

Ezt a sorozatot a make heap algoritmus segítségével kupaccá alakítjuk: 
make. heap(nums .begin() , nums . end()) ; 

Ekkor az alábbi eredményt kapjuk: 
S F34 2 

Ezek után hozzáteszünk a vektor végéhez egy elemet, melynek értéke 6. 
nums , push. back (6) ; 

Így a vektor elemei az alábbiak: 
543126 


Következő lépésként a hatot is beszúrjuk a kupacba a megfelelő helyre, ez a 
művelet a kupac átrendezését is okozhatja: 


Push. heap(nums . begin) , nums . end() ) ; 
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Ekkor az alábbi vektorhoz jutunk, amely így egy kupac adatstruktúra (amint 
azt az ábrán is láthatjuk): 





645123 


A pop. heap függvényt alkalmazva kivesszük a legnagyobb elemet a kupacról, 
ami esetünkben a 6: 


pop.heap(nums . begin) , nums . end()) ; 


Ekkor a legnagyobb elem a vektor végén található, és a vektor többi része ku. 
pacot valósít meg. 


543428 


Természetesen nem mindig szükséges elemenként manipulálni a kupacot. Az 
alábbi példaprogram kupacrendezéssel rendez egy nums nevű, egészeket tar- 
talmazó vektort. 


make. heap(nums . begin) , nums . end() ) ; 1 
sort. heap(nums . begin) ,nums.end()) ; z 


A vektor a következő számsorozatot tartalmazta: 

BÁSA tegye 
A make heap függvény által létrehozott kupac: 

54312 , eeöeseet 
A sort heap algoritmus pedig rendezte a kupacot: 


Megjegyezzük, hogy a fenti algoritmusokkal bármely tárolóból tudunk kupa- 
cot készíteni, amely támogatja a véletlen hozzáférésű iterátorokat. 


12.3.5. Rendezett tartományt feltételező algoritmusok 


A rendezett tartományt feltételező algoritmusokat azért tárgyaljuk külön fe- 
jezetben, mert speciális tulajdonságuknál fogva általában hatékonyabban old- 
ják meg feladatukat, mint ha nem lenne rendezve a rendelkezésre álló tarto- 
mány. Különösen fontos terület a keresés, amelyet számos példával illusztrá- 
lunk, és igyekszünk útmutatást adni a célnak legmegfelelőbb algoritmus ki- 
választásához. Ezek után a halmazműveleteket mutatjuk be. 
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12.3. Szabványos algoritmusok" 
Keresés rendezett tartományban 


A nem rendezett iterátortartományban való kereséssel a 
lalkoztunk. Rendezett iterátortartományban a binary se. 
upper. bound, egual. range függvényekkel kereshetünk, Mindegyik algoritmus 
paramétere előreléptető iterátor. Ezek az algoritmusok nem az egyenlőség 
koncepcióján alapulnak, mint a rendezetlen tartományon dolgozó keresések, 
hanem ekvivalenciát használnak. Ez nem meglepő, hiszen ezen az algoritmu- 
sok mindegyike a sorba rendezés köré épül, ami futási időben jelentős gyorsu- 
lást jelenthet. Mindegyik bináris keresést valósít meg, és minimalizálja az 
összehasonlítások számát, amely logaritmikus komplexitású bármely iterátor- 
típusra. Mivel csak a véletlen hozzáférésű iterátort lehet egy művelet alkalmá- 
val egyszerre többet léptetni, ezért csak ezek esetében lesz logaritmikus a lé- 
pésszám is (lásd 12.4.4. A tárolók műveleteinek összehasonlítása fejezet), a 
többi iterátortípusnál ez a rendezetlen tartományon dolgozó algoritmusokhoz 
hasonlóan lineáris.91 

A binary search algoritmust már a 12.1.3. pontban megismertük a 
lower. bound algoritmussal együtt. Az elsőt arra használtuk, hogy megtudjuk, 
benne van-e egy érték a tartományban, a másikkal meg is kerestük az ele- 
met. A lower bound és az upper bound függvény megértéséhez nézzünk egy 
példát! Adott az alábbi vektor: 


12.3.2. részben fog- 
arch, lower bound, 


int arr[]J-(1,2,3,3,3,4,5); 
vectorcints nums(arr,arrásizeof(arr)/sizeof(arr[0])); 


A kérdés, hová mutat a lower bound által visszaadott iterátor. Az alsó határ 
az a legelső pozíció, ahova beszúrhatnánk egy hármast a sorrend megbolyga- 
tása nélkül. Mivel mindig az adott pozíció elé szúrunk be, a keresett pozíció 
az első 3-as pozíciója, hiszen leghamarabb az első hármas elé szúrhatunk be 
egy új hármast. 

A felső határ, az upper bound esetén ugyanezt kell megvizsgálnunk, de 
itt arról a legutolsó pozícióról van szó, ahova az adott elem beszúrható. Pél- 
dánkban ez a négyes pozíciója, hiszen az elé szúrhatjuk be utoljára a hárma- 
sunkat. Ezt egyszerűen ellenőrizhetjük is: 








typedef vectorcints::íterator nums iíterator; 


nums iterator 1b - Tower. bound(nums . begin) , nums . end() , 3); 

nums iterator ub - upper. bound(nums . begin) , nums . end) , 3; 

cout cc "Tower bound position:" cc (1b-nums.beginO)) cs " value: 
cc t1b cc endi; f F: 

cout ce "upper bound posítion:" ac (ub-nums.begin0) cg " value: 
cz tub cc endi; 


"Az algoritmusok belül az advance sablonfüggvényt használják, amely másként példány: 
sul az egyes iterátorkategóriákra, így ki tudja használni a véletlen hozzáférésű iterátc 
adta lehetőségek 


Idányo 
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A program kimenete az alábbi: 









7 TENMANEZBET lézi vez TA SIZ3A HO I ETBASZAT, 
PÖGÁATS ater ree sa EEgnbstértel 
Ha figyelembe vesszük, hogy a pozíciókat nullától kell számolnunk, azt mond. 


hatjuk, hogy a gyakorlat igazolta feltevésünket. 
Már csak egy esetet kell megvizsgálnunk: mi a helyzet akkor, ha a vek- 


torban nincs hármas? Az előbbi példa vektorát most úgy töltjük fel adatokkal, 
hogy az előbbi sorozatból hiányozzanak a hármasok: 


E sántartTJEti, 274, Spa eme EZRET ötálrébnr b ae tre S ÉNVEDE 





Az előbbi megfontolásokból az következik, hogy — mivel a rendezettség megsérté- 
se nélkül csak egy pozícióba kerülhet hármas, nevezetesen a négyes elé — mind- 
két határ a négyes pozíciójába fog mutatni. A program kimenete is igazolja ezt: 





Érdemes megfigyelnünk, hogy ha a lower bound és az upper. bound függvény 
által visszaadott iterátorokat tartománynak tekintjük, akkor megadja a hár- 
masok helyét. Minden stimmel: a kezdő iterátor az első pozíciót tárolja, a be- 
záró iterátor az utolsó érvényes elem, vagyis hármas után mutat. Ha pedig 
nincs olyan elem, akkor mindkét iterátor érvénytelen elemre mutat. Ezt a két 
iterátort egy párban adja vissza az egual range. Íme erre is egy példa: 





A kimenet pedig ugyanaz: 


Ha a sorozatban nincs hármas, akkor természetesen szintén a lower. bound 
és az upper. bound függvényeknél tapasztalt értékeket kapjuk vissza. 
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Emlékezzünk vissza, milyen bonyodalmas voi i i 
tékének elemzése: meg kellett néznünk, hokő Herhetstás EAGeyéa zt b. 
szigorú gyenge rendezés szerint kellett megvizsgálnunk hogy hérn Ta ia 
ték tényleg megegyezik-e a keresett értékkel. Arra is oda kellett fg HÁG lk 
hogy ha megadtunk egy összehasonlító műveletet a lower bound. HAB AES 
azt használjuk az eredmény ellenőrzéséhez is. Ennél nagysái Hákk. 1 ez 
szerűbb az egual range két iterátorának összehasonlítása, FENÉT § sal. 
akkor van olyan elem, amelynek az első előfordulását az első Hórátátjolólt ki, 
az utolsó keresett elem pedig a második iterátor előtti pozícióban SE "Ha A 
1 JELZÁJESA ez azt jelenti, hogy a keresett elem nincs A megadott 

Az algoritmusok közötti választási szempontokat útmutatóban foglaljuk 
össze. 


FT VST ZT ESOEZTS ESNE NEEE KUNKOSKANTT CO TE ZENE ETT EZRET EE ez get e AA 
Útmutató: 


— Ha csak azt szeretnénk tudni, hogy egy elem benne van-e a tartományban, használjuk a 
binary. serach függvényt! 


— Ha azt is szeretnénk tudni, hol van az adott elem, használjuk az egual range függvényt! 


— Ha az összes keresett elemet vagy azok számát szeretnénk tudni, akkor szintén az 
egual range függvényt érdemes használni. 


— Ha be szeretnénk szúrni egy elemet, és a helyét keressük, akkor válasszuk a lower 
bound függvényt. jó 


— Ha a sorrend is számít, és a beszúrandó elem utolsó pozícióját keressük, akkor az upper 
bound a legmegfetetőbb. 





Asszociatív tárolók esetén ugyanilyen nevű tagfüggvények állnak rendelkezé- 
sünkre. Ha azt szeretnénk vizsgálni, hogy egy rendezett iterátortartomány 
részhalmaza-e egy másik rendezett iterátortartománynak, akkor az includes 
algoritmus nyújt megoldást, amelyet a következő fejezetben tárgyalunk. 


Halmazműveletek 


A halmazműveletek nem feltétlenül várnak set, illetve mudltiset típusú tároló- 
kat, tetszőleges rendezett tartományt várnak bemeneti iterátorokkal. 

Az includes két rendezett iterátortartományt vár, és azt vizsgálja, hogy a 
második iterátortartomány által meghatározott elemek egyenként benne 
vannak-e az első iterátortartományban. Az includes tulajdonképpen megvizs- 
gálja, hogy a másodikként megadott tartomány részhalmaza-e az első tarto- 
mánynak, Ha adott egy nums vektor az 1,2,3,4,5 számsorozattal és egy nums2 
Vektor az 1,3,5 rendezett sorozattal, akkor az 


" imelüdésnuns . begin , nums . endC) , nútis2 :begTNO , numSZENAOJT 
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függvényhívás igazzal tér vissza. Ha egy elemet többször is felsorolunk a ke. 
resendő elemek tartományában, akkor annak a keresett tartományban leg- 
alább annyiszor kell előfordulnia. Az algoritmus ekvivalenciát vizsgál, amit 
egy opcionális utolsó argamentumként mi is megadhatunk egy kétargumen- 
tumú predikátummal. 

A továbbiakban feltételezünk egy nums vektort: 





Továbbá egy target nevű iterátort, amely lehet például egy tároló beszúróite- 
rátora, de akár egy ostream. iterator is. 

A következőként bemutatott műveletek rendezett tartományt várnak és 
adnak vissza, eredményük stabil, mivel a bemeneti tartományok relatív sor- 
rendjét a kimeneti tartományban megőrzik. A bemeneti tartományokat egyik 
függvény sem módosítja. Ezek az algoritmusok ekvivalenciát használnak, 
ahol az összehasonlítást vagy egy opcionálisan megadott kétargumentumú 
predikátum adja, vagy ha az nincs, az elemek c operátora. 

A set union algoritmus két rendezett iterátortartományt fésül össze egy 
harmadik iterátortartományba. Egy elem annyiszor fordul elő az unióban, 
amennyi az egyik, illetve a másik tartományban való előfordulás maximuma. A 





kódrészlet eredménye az alábbi: 


TESZ B TSA SEEN SÁR TVE TE E OZ ZAGEKRSEBB 


Ha azt szeretnénk, hogy egy bizonyos értékű elem csak egyszer forduljon elő, 
akkor a művelet eredményére hívjuk meg a 12.3.3. pontban tárgyalt unigue 
függvényt, vagy használjuk kimenetként a set tárolót. 

A set intersection művelet a mindkét rendezett tartományban megtalál- 
ható elemet írja ki a megadott iterátortartományba. Egy elem annyiszor for- 
dul elő a metszetben, amennyi az egyik, illetve a másik iterátortartományban 
való előfordulás minimuma. Vagyis a 


eredménye az 


ÚEÉEEMESZZ KK ESZ EST ÜST EZ ZNES 


számsorozat. 








12.3. Szabványos algoritmusok" 


A set difference algoritmus az első tartomány azon ele: 
amelyek nincsenek benne a másodikban. A 


meíivel tér vissza, 





algoritmus a 
REYETABNTTE T FTV ATTIS 


rendezett sorozattal tér vissza. Jól látható, hogy ha több ekvivalens elem van, 
akkor csak annyi jelenik meg a kimeneti tartományban, amennyivel több van 
belőle az első bemeneti tartományban. 

A set symmetric difference algoritmus visszatér az összes elemmel, amely 
nincs benne a két halmaz metszetében. A 













" setosymmetric.difference(nums , béginÖ , nun . 
isi ségpokestikose 


hívás eredménye az alábbi: 
"23447 TE TÜNETE NET TES KIGYERNAKZÁNAAI 


12.3.6. Numerikus algoritmusok 


A numerikus algoritmusok a szabványos numeric állományban találhatók. 
Ezek az algoritmusok alapértelmezésben egyszerű, szorzásra és összeadásra 
épülő műveleteket hajtanak végre. Igazi rugalmasságukat az jelenti, hogy az 
egyes alapműveletek sablonparaméterként megadhatók, így a beépített függ- 
vényobjektumok, illetve a saját magunk által írt műveletek segítségével gyor- 
san és hatékonyan használhatjuk a numerikus algoritmusokat, amelyeket az 
alábbi feladattal illusztrálunk. 

Feladat: Az Egyesült Államokba látogatunk, ahol csak dollárt költünk, de kizárólag 7000 eu- 
rót viszünk magunkkal. Egy usd nevű vektorban tároljuk, hogy az elmúlt héten naponta mennyi 
USA-dollárt vásároltunk meglévő eurónkért. 


— Számítsuk ki, hogy hány dollárt vásároltunk! 


7 Egy spent nevű vektorban tároljuk, hogy hány dollárt költöttünk naponta. Számoljuk ki, 
hány dollárunk van most! 


7 Egy eurusd vektorban rendelkezésre áll a napi euró-dollár árfolyam. Egy ismerősünk háti 
dollárban számolta a vásárolt valutát, hanem azt jegyezte fel, hogy mennyi eurót köl- 
tött dollárra (friendEuro vektor). Számítsuk ki, hány dollárt vásárolt az ismerős! 


— Számítsuk ki, hogy összesen hány eurót költöttünk dollárra! 


7 Számítsuk ki, hány eurónk van most! 
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— Számítsuk ki, hány dollárt költöttünk az első napon, a második napig, a harmadik napig 
és így tovább a hetedik napig! 


Számítsuk ki, mennyít költöttünk az első napon, ílletve ennél mennyível többet a máso- 
dik napon, valamint a második nap kiadásainál mennyivel többet költöttünk a harmadik 
napon, és így tovább a hetedik napig! 


Egy iterátortartomány elemeit az accumulate algoritmussal összegezhetjük, 
Mivel az usd vektor tartalmazza a naponta vásárolt dollárösszeget, az usd 
vektorra lefuttatjuk az accumulate algoritmust. 





Az összegzendő iterátortartomány után az összegzés kezdeti értékét adhatjuk 
meg. Az accumulate az összegzés során az összeget egy belső változóban gyűj- 
ti, amelynek a típusát az implicit példányosítás miatt (lásd 11.1. Függvény. 
sablonok fejezet) a kezdeti értékként megadott kifejezés típusa adja meg. Va- 
gyis, ha 0.0 helyett 0-t írnánk, akkor az algoritmus az iterátortartomány ér- 
tékeinek egész részét adná össze. 

Ha azt szeretnénk kiszámolni, hogy hány dollárunk van, az előbb kiszá- 
molt összegből le kell vonnunk a költekezésünket, amelyet a spent vektor tar- 
talmaz. Ehhez is az accumulate algoritmust használjuk, csak a kezdeti érték 
az előbbiekben kiszámolt összes vásárolt dollár (bought USD) lesz, és az alap- 
értelmezett összeadást lecseréljük kivonásra: 





A kivonást a minus előredefiniált függvényobjektum egy double típusú példá- 
nyának átadásával biztosítottuk. 

Ismerősünk dollárját a napi dollárra költött euró és az 1 euró napi dollár- 
értékét tartalmazó vektor skaláris szorzataként határozzuk meg. Ez azt je- 
lenti, hogy az egy nap dollárra költött euró összegét megszorozzuk a dollár árfo- 


lyamával, és ezeket összegezzük. Pontosan ezt valósítja meg az inner product 
algoritmus. 


A példában az első iterátortartományt az első két paraméter, a második 
iterátortartományt annak eleje határozza meg, mivel a skaláris szorzás miatt 
a két tartománynak ugyanannyi elemet kell tartalmaznia. Az utolsó paramé- 
ter a szorzat kezdeti értéke. 

Az inner. product algoritmus két műveletet tartalmaz: az összeadást és a 
szorzást. Természetesen ezek a műveletek is lecserélhetők: a függvénynek to- 
vábbi két paramétert adhatunk meg, az elsőt az összeadás helyett, a másodi- 
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kat a szorzás helyett alkalmazza. Ha azt szeretnénk kiszámolni, hogy mennyi 
eurót költöttünk, akkor a napi elköltött dollárösszeget el kell osztanunk a napi 


árfolyammal. Vagyis a szorzást osztásra kell cserélnünk, és az algoritmus 


azon verzióját kell használnunk, amelynek az argumentumlistáján a függvé- 
ktor, a dollár napi 


nyeket is meg lehet adni. A vásárolt dollárösszeget az usd ve. 
árfolyamát az eurusd vektor tartalmazza. 






nt - inner.p 
eurusd.begini 





Az összeadás és a szorzás műveletét ismét előredefiniált függvényobjektumok- 
kal adtuk meg. Ha ki szeretnénk számolni, hány eurónk van most, akkor a vitt 
7000 euróból kivonjuk azt az összeget, amit dollárvásárlásra fordítottunk. 





sz c ui B, m tk ve 
JESZS se tbe Ő; 7000.0, minus cdoub 


iroBalance - ínner. product(usd.beginŐ , 





Ha azt szeretnénk kiszámolni, hogy egy adott nappal bezárólag mennyit köl- 
töttünk, akkor a partial sum függvényt alkalmazhatjuk. Ennél az algorit- 
musnál a kimeneti iterátortartomány n. pozíciójába a bemeneti iterátortarto- 
mány elemeinek 


n 
Xbemeneti; 


összege kerül. Az alábbi példában a szabványos kimenetre írjuk az eredményt. 


"  partial.sum(spent.beginO) , spent.end() , 
3 ostream iteratorcdoubles (cout," ")); 


Természetesen a partial sum összeadásművelete is lecserélhető, feladatunk 
megoldásához azonban ez nem szükséges. 

Az egyes napok költekezései közötti különbséget az adjacent difference 
algoritmussal számíthatjuk ki. 






.  adjacent difference(spent.begin) , spent. endi 
Enter ostream iteratoredoubles (cout, " b 





A kimeneti tartomány első eleme a bemeneti tartomány első eleme, a többi 
pedig a bemeneti tartomány adott pozíciójú elemének és az azt: megelőző 
elemnek a különbsége. A kivonás itt is lecserélhető. Ezzel a kitűzött felada- 
tunkat megoldottuk. 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 


12.4. STL tárolók" 


Az STL tárolók olyan objektumok, amelyek képesek más objektumokat tárolni, 
A tároláshoz szükséges memóriafoglalás és -felszabadítás a tároló feladata, 
Hangsúlyozzuk, hogy ez csak a tároláshoz szükséges memóriakezelésre vo. 
natkozik, vagyis, ha pointereket tárolunk, a pointerek tárolásához szükséges 
memória kezelése a tároló hatásköre, de a mutatott memóriaterület kezelésé. 
ről a tároló már nem gondoskodik. 

A tároló elemeinek mindig van egy adott sorrendje. Vagyis, ha egymás 
után többször végigiterálunk a tárolón, feltételezhetjük, hogy ugyanabban a 
sorrendben kapjuk vissza az elemeket. A visszaadott iterátorok az egyes mű- 
veletek után érvénytelenné válhatnak. Hogy melyek ezek a műveletek, azt 
végső esetben az STL dokumentációjából vagy bármely referenciakönyvből 
megtudhatjuk, ugyanakkor ez elég intuitív. Azok a konstans műveletek, ame- 
lyek nem változtatják a tároló állapotát, nem érvénytelenítik az iterátorokat 
sem. Azok a műveletek, amelyek megváltoztatják a meglévő adatszerkezetet, 
érvénytelenítik az előzőleg lekérdezett iterátorokat. Például a beszúrás vek- 
tor esetén elcsúsztatja eggyel az elemek fizikai sorrendjét, tehát a beszúrás 
előtt visszaadott iterátorok az elemek régi helyére mutatnak, vagyis érvény- 
telenek. Ha újra kell foglalni a memóriát, akkor az összes iterátor érvényte- 
lenné válik — ez bármelyik beszúrást végző művelet esetén előfordulhat. Tör- 
lés esetén a kitörölt elemeket megelőző elemek iterátorai érvényesek marad- 
nak. Az asszociatív tárolók és listák esetén a beszúrás nem érvényteleníti az 
iterátorokat, a törlés is csak azokat, amelyeket töröltünk. 

Minden tárolónak van alapértelmezett konstruktora, másolókonstruktora 
és egy olyan konstruktora, amely iterátortartományt vár, és annak tagjaival 
inicializálja a tárolót. 

Egyik tárolónak sem virtuális a destruktora, ezért az STL tárolókból nem 
szabad leszármaztatnunk. 


Útmutató: Sose származtassunk le STL tárolóból! Ha erre lenne szükség, 


— nézzünk utána, nem alakítható-e át a tároló függvényekkel, predikátumokkal, függvény- 
objektumokkal, sablonparaméterekkel és egyéb mechanizmusokkal, hogy biztosítsa a 
szükséges viselkedést, vagy 


— használjunk csomagolóosztályt: ennek egy tagváltozója a tároló, és tagfüggvényei hívják 
a tároló hozzáférhetőnek szánt tagfüggvényeít, vagy további/megváltoztatott funkciót 
valósíthatnak meg a tároló segítségével. Példaként tekinthetjük a 12.4.1. Szekvenciális 
tárolók fejezet Tárolóadapterek részében található tárolóadapterek interfészét és nyílt 
forráskódú implementációit. 

eeeesskbszáiszmkelnászülászikezssztsts ző dereleéséséter sztésa eöztzkászésákeei 27. Dvd ék 





Az elemszám lekérdezésével kapcsolatos tagfüggvények a size és az empty 
tagfüggvények: az első bármely tároló esetén visszaadja a tárolóban lévő ele- 
mek számát, a második pedig igazzal tér vissza, ha a tároló üres, egyébként 
hamissal. A max size tagfüggvény a lehetséges elemek maximális számával 
tér vissza, ezt a tároló memóriagazdálkodása határozza meg. 

A tároló összehasonlítható más tárolókkal, minden tároló támogatja eze- 
ket az operátorokat (——, !1-, c, 5, cz, 57). Az összehasonlítás elemenként, a 
lexicographical compare() algoritmussal történik, az elemek sorrendjének és 
a tároló típusának is meg kell egyeznie. Az értékadás (- operátor) elemenként 
másolja le a tárolót az elemek -— operátorának segítségével. A swap tagfügg- 
vény megcseréli a két tároló tartalmát. Ez igen gyors művelet, mert csak a 
belső adattagokat kell kicserélni, így az egyes implementációk sokszor csak a 
belső adatokra mutató pointerek értékeit cserélik meg. 

A tárolók közös iterátorfelületét a már jól ismert begin, end, rbegin és 
rend tagfüggvények teszik elérhetővé. A beszúrásra az insert, a törlésre az 
erase tagfűggvények szolgálnak, a clear művelet pedig az összes elem eltávolí- 
tásával kiüríti a tárolót. 

Az STL tárolók nem szálbiztosak, habár ezt néhány implementáció (pél- 
dául SGI) támogatja, általános esetben többszálú környezetben nekünk kell 
gondoskodnunk a tárolók védelméről. 

A tárolókban tárolható elemek 7 típusával szemben az STL az alábbi kö- 
vetelményeket támasztja: 


s érvényes, konstans elemet is fogadni képes másolókonstruktor: pél- 
dául T(const T£), 


e destruktor: -70), 


s  címképző operátor (£), amely képes az adott típus, illetve konstans 
típus objektumainak címét képezni, 


s egy referenciával visszatérő - operátor, amely képes konstans objek- 
tumot fogadni jobbértékként: például T£ T::operator-(const T8). 


Természetesen egyes tárolók, illetve tárolótípusok további követelményeket 
írhatnak elő, a fentieket minden tároló megköveteli. A követelmények közül 
az érvényes destruktort, az - operátort és a másolókonstruktort emeljük ki. 
Ezekből ugyanis mindig létezik alapértelmezett, amely esetleg rosszul mű- 
ködhet. A címképző operátorból szintén van alapértelmezett, amely az esetek 
túlnyomó többségében megfelelő. 
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Útmutató: Ha dinamikus adattagokat tartalmazó osztályok objektumait szeretnénk STL táro. 
lókban elhelyezni, írjunk 


— másolókonstruktort, 
— operátort 
— és destruktort! 
Ha objektumokra mutató pointereket szeretnénk eltárolni egy STL tárolóban a polimorfizmus 


lehetőségeinek kihasználása végett, ne felejtsük el felszabadítani a pointerek által mutatott 
memóriaterületet, és deklaráljuk virtuálisnak a destruktort! 


Az STL tárolók tagfüggvényei nem végeznek hibakezelést, nem dobnak kivéte- 
leket, hacsak az elemek meghívott tagfüggvényei nem tesznek ilyet. Ez szán- 
dékos döntés: a hatékonyságot szolgálja. Ezért az egyes műveletek paraméterei. 
nek érvényességéről nekünk kell gondoskodnunk. Ügyeljünk rá, hogy ne ad- 
junk meg érvénytelen iterátorokat vagy tartományokat, illetve a tartományok 
bejárhatók legyenek. Természetesen fejlesztés közben mindig elronthatunk 
dolgokat, ezért a legtöbb STL implementáció nyomkövető üzemmódban (jellem- 
zően akkor, amikor definiáljuk a DEBUG vagy valami hasonló makrót) ellenőrzi 
a bemeneti adatokat, és futásidejű hibaüzenetet kapunk. 


12.4.1. Szekvenciális tárolók 


A szekvenciális tárolókban a tároló felhasználója határozza meg a sorrendet. 
Az STL három szekvenciális tárolót tartalmaz: a vector, a list és a degue osz- 
tályt. Ezek a tárolók különböző komplexitással valósítanak meg bizonyos mű- 
veleteket, és a programozóra van bízva, hogy az adott feladat tükrében me- 
lyik tárolót választja. A szabvány alapértelmezett választásként a vektort ja- 
vasolja. A lista akkor kifizetődő, ha sokszor kell beszúrnunk elemeket a tároló 
közepébe, vagy sokszor kell törölnünk onnan. Ha a beszúrások és a törlések a 
tároló elején és végén gyakoriak, akkor a degue a megfelelő választás. 


Vektorok és listák: további lehetőségek 


Ebben a fejezetben közelebbről megvizsgáljuk a vektorok és a listák belső fel- 
építését és néhány ritkábban használt, de igen hasznos funkciójukat. 

A vektorok lényegében dinamikus tömbök, amelyek folyamatos memória- 
területen helyezkednek el. Az egyszerű tömbökhöz hasonlóan lehetőség van 
az indexelt hozzáférésre, amely igen gyors. A vektor véletlen hozzáférésű 
iterátorokat támogat. A vektor végéhez fűzni egy új elemet, vagy onnan tö- 
rölni egy régit gyors művelet. Más esetben az elemeket odébb kell csúsztatni, 
ami sok másolási műveletet eredményez. Ha a tárolt elemtípus másolókonst- 
ruktora és — operátora nem dob kivételt, a vektor műveletei vagy sikeresek, 
vagy nem csinálnak semmit. 





A vektor a kapacitás bevezetésével optimalizálja a memóriafoglal ást: 
a mechanizmust a 12.1.1. Tárolók fejezet Dinamikus tömb Tészéböin iát vág. 
ismertük. Megemlítjük még a resize függvényt, amely a paraméterként meets 
adott nagyságúra állítja a vektor elemeinek számát. Ha ez a szám 5 föbb, 
mint a vektor eredeti mérete, akkor az elemek alapértelmezett Ködétlukíeé Át 
hívja meg az újonnan keletkezett üres helyek feltöltésére. T z 
A tömbök és a tárolók egymással kompatibilisek, mivel az i 
ter általánosítása, pointer is átadható iterátor helyett. Példá 
inicializálhatunk pointerekkel is az iterátortartományt váró 
keresztül: 
"ant t[(J-f1,2,3,4); ; 


vectorxchars v(t,tisizeof(t)/si zéSFtÉlOiJje gi 


terátor a poin- 
ul egy vektort 
konstruktorán 


Ez nemcsak vektorra, hanem minden tárolóra elvégezhető. 

Mivel a vektor gyakorlatilag folyamatos memóriaterületen tárolja az ele- 
meit, tömbként is használhatjuk. A következő összefüggés igaz: €rv/ij- 
-gv/0]i, és érdemes megfigyelni, hogy nem a vektor begin tagfüggvény által 
visszaadott iterátorán keresztül képezzük a tömb kezdőcímét, mert az sok- 
szor működik, de nem minden implementációnál, Ehelyett a nulladik elem 
címéből nyerjük a tömb kezdőcímét. Figyeljünk arra, hogy a vektor ( ] operá- 
tora nem végez indexhatár-ellenőrzést. A vektor tömbként való kezelését il- 
lusztrálja az alábbi példa: 


vectorcchar: s; 

s.resize(255); // Sok helyet foglalunk 
 strepy(és[0] , "Heidegger"); // a "N0" is a végére került 
printf("ssWVa" 4510]; 


A fenti kódrészlet szemlélete természetesen nem objektumorientált és nem is 
Cs szellemiségű, ugyanakkor a gyakorlatban sokszor kell már elkészült C 
kóddal kommunikálnunk (általában az operációs rendszerek C nyelvű prog- 
ramozási felületeivel), és ekkor hasznosnak bizonyulhat ez az átjárhatóság. 

Említettük, hogy az STL list implementációja gyakorlatilag kétszeresen 
láncolt lista. Ez azt jelenti, hogy a beszúrás és a törlés nemcsak a két végén 
gyors, hiszen csak néhány pointert kell átállítani. Mivel a kétszeresen láncolt 
listát oda és vissza lehet bejárni, ezért a tároló kétirányú iterátorokat támo- 
gat. Ha indexelve akarunk hozzáférni az elemekhez (például a 3. elemhez), 
akkor végig kell iterálnunk a listán, ami semmivel sem hatékonyabb a 
for. each algoritmusnál. Ezért a lista tagfüggvényei nem támogatják a vélet- 
len elemhozzáférést. Hasonló megfontolások miatt a keresés sem gyorsítható 
az általános algoritmusokhoz képest, ezért nincs is erre külön tagfüggvény. 

Az elemek eltávolítására a lista hatékony tagfüggvényeket biztosít: A 
remove a listából eltávolít minden elemet, amely az elem —— operátora szerint 
megegyezik a remove-nak átadott értékkel. A remove if az operátor helyett 
függvényobjektumot vár. 
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A lista számos hatékony műveletet biztosít. Ezek közül a legfontosabb a 
splice95 tagfüggvény, amelynek három változata van: 


void splice( 
iterator where, 
Tistg Right 


d; 

void splice( 
iterator Where, 
Tisté Right, 
iterator First 


); 

void splice(C 
iterator where, 
Tisté Right, 
iterator First, 
iterator Last 

); 


Az első verzió veszi a második paraméterben megadott listát (Right), és az 
összes elemét átfűzi az első paraméterként megadott iterátor (Where) elé. Az 
átfűzés azt jelenti, hogy néhány belső pointer átállításával, az elemek máso- 
lása nélkül átveszi az elemeket a megadott listától, amely ezután értelemsze- 
rűen üres lesz. A második splice átfűzi a második paraméterben megadott lis- 
ta (Right) elemeit a harmadik paraméterben megadott iterátortól (First) kez- 
dődően a megadott iterátor (Where) elé. Itt a forrás- és a céllista lehet ugyan- 
az. A harmadik splice annyiban különbözik a másodiktól, hogy nemcsak a 
szekvencia elejét, hanem egy egész tartományt megadhatunk. 

A lista rendezőfüggvényeket is tartalmaz. A reverse tagfüggvény megfor- 
dítja az elemek sorrendjét. A sort() tagfüggvény rendezi a tárolót az elemek c 
operátora segítségével, míg a túlterhelt változatának függvényobjektumként, 
illetve predikátumként adhatjuk meg a szigorú gyenge rendezést megvalósító 
műveletet. A merge tagfüggvény egy rendezett listával összefűz egy másik 
rendezett listát úgy, hogy az elemek az összefűzés után is rendezettek legye- 
nek. Ennek is megadható az összehasonlítást végző művelet. 


Degue 


A degue" (double-ended gueue, kétvégű sor), lényegében abban különbözik a 
vektortól, hogy nemcsak a végén gyorsak a műveletek, hanem az elején a törlés 
és a beszúrás is hatékony. Ezeket a műveleteket a push front, pop. front tag- 
függvények valósítják meg. A degue a vektorokhoz hasonlóan véletlen hozzáfé- 
résű iterátort támogat. Használatához a degue állomány beépítése szükséges. 





"5 A splice szó két kötél összetoldását jelöli a végeik összeszövésével. Itt két listarészlet ha- 
sonló csatlakoztatásáról van szó. 
"8 Ejtsd: dekk 
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12.4. STL tárolók" 
A belső adatstruktúra több memóriablokkból áll: az első 
első 1 pi vi ső bl. 
eleje felé nő, az utolsó blokk a vége felé. Így a tároló mindkét szátu ta tolt 
változtatni a méretét anélkül, hogy az összes elemet át kellene mozgatnia 58 


Degue aal 


1 Degue vége 


31. ábra. A degue egy lehetséges belső felépítése 


A vektorral összevetve további különbséget jelent, hogy a több memóriablokk 
miatt az elemhozzáférés valamivel lassabb, nem folytonos memóriaterületen 
tárolja az elemeket, így nem használható C tömbként. A degue automatiku- 
san intézi a memóriafoglalást. Ezért nem állíthatjuk a kapacitást (nincs 
reserve, illetve capacity tagfüggvénye), és minden beszúrás és törlés érvényte- 
lenítheti az iterátorokat. A degue felszabadítja a kihasználatlan memóriát, de 
implementációfüggő, hogy mikor. Ugyanakkor a blokkos elrendezés miatt be- 
szúráskor és törléskor nem kell elcsúsztatni az összes elemet, elég csak az 
adott blokkon belül, úgyhogy ebben a tekintetben a degue hatékonyabb lehet, 
mint a vektor. 


Tárolóadapterek 


Az eddig tárgyalt szekvenciális tárolók adatstruktúráival nagyon sok feladat 
megoldható. Bármelyik tárolót alapul véve kialakíthatunk például FIFO és 
LIFO struktúrákat. Ugyanakkor ehhez érdemes lekorlátozni az eddigi elem- 
hozzáférési lehetőségeket, nehogy véletlenül egy FIFO-n nem megengedett 
műveletet végezzünk. Az STL ebben is a segítségünkre lesz: tárolóadaptere- 
ket bocsát rendelkezésünkre. A tárolóadapterek (container adapters) egy- 
ségbe zárnak egy tárolót, amelyekhez csak az adapter tagfüggvényein keresz- 
tül férhetünk hozzá. Az STL tárolóadapterei csak szekvenciális tárolókat zár- 
nak egységbe. Ezek a tárolóadapterek nem támogatják az általános iterátor- 
interfészt, hiszen azon keresztül megsérthetjük az elemhozzáférés szabályait. 
Az STL három tárolóadaptert biztosít: 


, verem (Stack): LIFO tároló, az utolsó betett elemet vesszük ki legelőször 


. sor (Aueue): FIFO tároló, az először betett elemet vesszük ki legelőször 
"  prioritásos sor (Priority gueue): olyan tároló, amely az elemhez hoz- 
zárendelt prioritás alapján rendezi az elemeket, vagyis a legnagyobb 


prioritásút vesszük ki következő elemként. 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 
A fenti tárolóadapter alá bármelyik szekvenciális tárolót betehetjük, de min. 
degyiknek van egy alapértelmezett tárolója: a veremnek és a sornak degue, a 
prioritásos sornak vector. 

Verem osztályt a stack sablon példányosításával hozhatunk létre, amely. 
hez a stack állományt kell beépítenünk. Deklarációja az alábbi: 


Az első sablonparaméter a veremben tárolandó típus, a második egy szekven- 
ciális tároló, amelyben a verem az elemeket tárolja, jól látható, hogy ez alap- 
értelmezésben degue. 

A szokásos, egyéb tárolókra jellemző műveleteken (konstruktor, összeha- 
sonlítások, empty, size) kívül a verem három műveletet biztosít: 





e — push: lenyom egy elemet a verem tetejére 
e — pop: kivesz egy elemet a verem tetejéről 


e — top: visszaad egy referenciát a verem tetején lévő elemre 


Az alábbi kódrészlet beteszi egytől tízig a számokat egy egész típusokra pél- 
dányosított verembe, majd kiírja őket a kivétel sorrendjében, azaz fordítva. 





Mint említettük, az alapértelmezett degue tárolót kicserélhetjük például vek- 
torra: 





"am 





A sor osztályt a gueue sablon példányosításával használhai juk. 
méterei megegyeznek a veremével, implementációja a év. állóángban ez 
lálható. Négy jellemző függvénye van: 1 


e. push: betesz egy elemet a sor végére 
e — pop: kivesz egy elemet a sor elejéről 
e — front: visszaad egy referenciát az első elemre 


e — back: visszaad egy referenciát az utolsó elemre 


Használatának illusztrálására álljon itt egy példa: 





A prioritásos sort a priority gueue sablon példányosításával nyerjük az eddigi 
tárolóadapterekhez hasonlóan. Használatához a gueue-hoz hasonlóan a gueue ál- 
lományt kell beépítenünk. A prioritásos sornak van még egy sablonparamétere: 





Harmadik sablonparaméterként az összehasonlító műveletet adhatjuk meg, 
ez alapján rendez a prioritásos sor. Valahányszor beleteszünk egy elemet a 
prioritásos sorba, az összehasonlító műveletet felhasználva megkeresi a leg- 
nagyobb elemet, és az kerül a sor elejére. Ha több ilyen van, akkor ezek sor- 
rendje implementációfüggő. Jól látható, hogy az alapértelmezett rendezési elv 
a less függvényobjektum, amelyről tudjuk (12.2.2. Előregyártott függvényob- 
jektumok fejezet), hogy az elemek c operátorát hívja. 
A prioritásos sor jellemző műveletei nagyon hasonlítanak a vereméihez: 


§ push: lenyom egy elemet a sorba 
e pop: kiveszi a legmagasabb prioritású elemet a sorból 


§. top: visszaad egy referenciát a sor elején lévő elemre 
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12. fejezet: Bevezetés a Css szabványos sablonkönyvtárába 








Feladat: Példaként tároljunk különböző fontosságú üzeneteket a priorításos sorban! Az üze- 
netnek van szövege és prioritása (fontossága). Az üzenetnek írjunk c operátort, és kényelmi 
szempontokból tegyük lehetővé a kímeneti adatfolyamra történő kiírását. Mivel minde a leg- 
nagyobb prioritású üzenetet dogozzuk fel először , ezért az kerüljön ki legelőször a sorból! 





Megoldás 
Az üzenet osztály nem jelent különösebb nehézséget, viszont a feladat előírása, 
hogy a c operátor az üzenetek prioritása alapján végezze az összehasonlítást. 





class Message 


( 
friend ostream$ operatorcc(ostreamé, const MessageG); 


public: 
enum priority. type 
(LOW LIMPORTANCE , NORMAL. IMPORTANCE , HIGH. IMPORTANCE) ; 
private: 
string message; 
priority.type priority; 
public: 


Message(string message, priority. type priorityzNORMAL. IMPORTANCE) 
:message(message) , priority(priority)í(j 
boo1] operator z (const Messageg right)const 
(return priority c right.prioríty;) 
ns 


ostreamé operatorcc(ostream$g os, const Messageg message) 
£ 
oscc "Message: "cc message.message.c str() 
az ", Priority: "ccmessage.prioríty; 
return os; 
J 


Ezek után helyezzünk be három különböző prioritású üzenetet a sorba, és 
teszteljük, milyen sorrendben jönnek ki: 


priority. gueueMessages pg; 

pa.push(Message("Christmas greetings")); 78 
pa.push(Message( "Tornado warning" Message: : HIGH. IMPORTANCE) ) ; 
pa.push(MessageC"Puppies for sale" Message: : LOW. IMPORTANCE) ) ; 
siníjéljeg ekpey ny Eőloszé ze ágát özlk 
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Látható, hogy a prioritásos sor a prioritás alapján a c operátor segítségével a leg- 
fontosabb üzenetet hozta előre: a tornádóra való figyelmeztetés jögerén a kárá: 
csonyi köszöntésnél vagy az eladó kiskutyákról szóló, szívmelengető híradásnál. 


12.4.2. Asszociatív tárolók 


Az asszociatív tárolók kulcsokon keresztüli gyors elemhozzáférést biztosíta- 
nak. Az STL négy asszociatív tárolót biztosít, amelyek a következők: set, 
multiset, map, multimap. A set, illetve a map tárolókban egy kulccsal csak 
egy elem szerepelhet. A ,multi" előtagot viselő változatok esetén egy kulcsot 
többször is tartalmazhat a tároló. 

Az asszociatív tárolók biztosan rendelkeznek két sablonparaméterrel: a 
kulcs típusával és egy összehasonlító művelettel, amely megfelel a szigorú 
gyenge rendezés szabályainak. Ez utóbbi alapértelmezetten a less függvény- 
objektum, amely a kulcs c operátorát használja, de szokás szerint sajátot is 
írhatunk. Ha tehát az alapértelmezést használjuk, az elem típusának érvé- 
nyes c operátorral kell rendelkeznie. Az asszociatív tárolók kétirányú iteráto- 
rokkal dolgoznak. Amikor végigiterálunk egy asszociatív tárolón, az elemek 
kulcs szerinti nem csökkenő sorrendben követik egymást. A beszúrást végző 
műveletek nem érvénytelenítik az iterátorokat, a törlést végző műveletek pe- 
dig csak a törölt elemekét. 


Halmazok és multihalmazok 


A halmazok és a multihalmazok egy megadott feltétel alapján rendezve tárol- 
ják az elemeket. A különbség közöttük annyi, hogy a halmazban nem tárolha- 
tunk két ekvivalens kulcsú elemet, míg a multihalmazban igen. Mindkettő- 
höz a set állományt kell beépítenünk. Gyakorlatilag ezek a tárolók kiegyensú- 
lyozott bináris fákban (úgynevezett piros-fekete fákban) tárolják az adatokat. 
Mivel a bináris fában az elem értéke határozza meg az elem helyét, a tároló- 
ban levő elem értékét nem változtathatjuk. 

Mível a halmazok és multihalmazok belső szerkezete hatékony keresést tesz 
lehetővé, nem érdemes olyan általános megoldásokat választani, amelyek nem 
használják ki a bináris fa nyújtotta előnyt. Ezért az általános algoritmusok he- 
lyett érdemes a tagfüggvényeket választani a kereséshez. Ezek az alábbiak: 


s count: megszámolja, hogy egy adott értékű elem hányszor van a táro- 
lóban. 

" find: visszatér egy adott értékű elem első előfordulásának pozíciójával 
vagy az end() által visszaadott iterátorral. 
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e. lower bound: az első pozíció, amely elé a megadott elemet be lehetne 
szúrni, 

e upper. bound: az utolsó pozíció, amely elé a megadott elemet be lehetne 
szúrni. 

e egual range: az első és utolsó pozíció, amely elé az elemet be lehetne 


szúrni. 


Megfigyelhető, hogy a fenti tagfüggvények paraméterei — az értelemszerű 
egyszerűsítésektől eltekintve, amelyet tagfüggvény mivoltuk tesz lehetővé — 
megegyeznek az azonos nevű általános algoritmusokkal, ugyanakkor jóval 
gyorsabbak. 

A 12.1.1. Tárolók fejezet Halmazok részében megvizsgáltuk a set insert tag. 
függvényét, amely egy párral tért vissza. A pár második tagja egy bool érték 
volt, amely megadta, hogy az elem benne volt-e a halmazban. Ha benne volt, 
akkor még egyszer nem került bele, ha nem volt a halmazban, akkor beleke- 
rült. A pár első tagja mindkét esetben az adott elemre mutató iterátort adta 
vissza. A multiset esetében erre nincs szükség, a beszúrandó elem ugyanis min- 
denképp belekerül a multihalmazba, vagyis a multihalmaz beszúrófüggvénye 
mindig a beszúrt elemre mutató iterátorral tér vissza. 

Ha törölni szeretnénk egy elemet, az erase tagfüggvényt hívjuk. Az erase 
képes egy iterátorral megadott pozícióban lévő elemet, egy iterátorral meg- 
adott tartományt, valamint egy megadott értékű elemet törölni.97 Ez utóbbi 
az összes megadott értékű elemet törli. Ez multihalmaz esetében jelent kü- 
lönbséget. Ha az elemnek csak az első előfordulását szeretnénk törölni a 
multihalmazból, előbb meg kell keresnünk az elemre mutató iterátort a find 
tagfüggvénnyel, majd azt az egy elemet kell törölnünk az iterátor által meg- 
adott pozíció alapján (erase). Figyeljünk arra, hogy a törlés érvényteleníti az 
iterátort, ezért utána már nem léptethetjük. Erre a következő fejezetben mu- 
tatunk példát map és multimap esetén, amely értelemszerű módosításokkal 
könnyen alkalmazható halmazokra és multihalmazokra is. 


Asszociatív tömbök 


Az asszociatív tömböket a map és a multimap osztályok valósítják meg, 
mindkettő a map állományban található, amit használatukhoz be kell építeni. 
Az asszociatív tömbök abban különböznek a halmazoktól, hogy míg a halma- 
zoknál az érték és a keresés alapjául szolgáló adatstruktúra, a kulcs egy és 
ugyanaz, az asszociatív tömböknél ez a kettő különválik. Így külön megadhat- 
juk a kulcsot, amely alapján a rendezés történik, és a kulcshoz rendelt adatot. 





" A szabvány szerint az erase függvényeknek szekvenciális tároló esetén a törölt elem utá- 
ni elemre mutató iterátorral kell visszatérniük. Asszociatív tárolók esetén a visszatérési 
érték void, hiszen egy bináris fában több idő megkeresni a soron következő elemet. 
Ugyanakkor a Dinkumware STL-ben az asszociatív tárolók is a soron következő elemmel 
térnek vissza, amit a dokumentáció meg is említ mint a szabványtól való eltérést. 
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SZEGETT ÉRE NE GT GT NT zet 

A kulcsot nem változtathatjuk, az adatot igen. Mindebből egyen 

keznek a sablonparaméterek: a kulcs típusa, a tárolandó adat típusa és jóm 

kásös jérásszetág ál művelet, amely alapértelmezésben a less függvényobjek. 

tum, amely a kulcs c operátorát hívja. A map-ben nem leh y 6 

kulcs, a multimap-ben igen. ehet két ekvivalens 
A halmazokhoz hasonlóan az asszociatív tömbök is bináris fában tárolják 

az elemeiket, így ezek a tárolók is speciális tagfüggvényeket bi 

resésre az általános algoritmusok helyett: 97 iztosítanak ke- 


s count: megszámolja, hogy egy adott értékű kul, 


j. cs hányszor van a táro- 
lóban. 


e find: visszatér egy adott értékű kulcs első előfordulásának pozíciójával 
vagy az endí() által visszaadott iterátorral. 


s lower bound: az első pozíció, ahova a megadott kulcsot be lehetne 
szúrni. 


e upper bound: az utolsó pozíció, ahova a megadott kulcsot be lehetne 
szúrni. 


e egual range: az első és utolsó pozíció, ahova a kulcsot be lehetne 
szúrni 


A keresőműveletek argumentuma a kulcs, hiszen a rendezés is a kulcs alap- 
ján történik. Az iterátorinterfészen keresztül nem változtathatjuk a kulcsot, 
ám a kulcshoz rendelt értéket igen, természetesen csak akkor, ha annak típu- 
sa nem konstans. 

Ahogy ezt a halmazoknál és multihalmazoknál láttuk, a beszúrás a táro- 
lók jellegénél fogva különbözik a két tárolóban. 

A map esetén vagy az insert tagfüggvényt használjuk, vagy az ( ] operátort. 
Az insert tagfüggvény bemenő paramétereként egy párt vár, amelyet leggyak- 
rabban a make pair sablonnal hozunk létre. Visszatérése szintén egy pár: az 
első a beszúrandó kulcsú elemre mutat, amely egy (kulcs, érték) pár; a vissza- 
adott pár második eleme egy bool érték, amely igaz, ha a megadott kulccsal 
nem volt még elem a tárolóban, és így sikeres volt a beszúrás, ellenkező esetben 
hamis, Ha volt ilyen kulccsal rendelkező elem a tárolóban, akkor az insert azt 
az elemet érintetlenül hagyja — még akkor is, ha a beszúrandó elem értéke más 
volt -, és erre a párra fog mutatni a visszaadott pár első, iterátor típusú eleme. 
Ha nem volt benne ez az elem, akkor az ínsert beszúrja, és a visszaadott pár első, 
iterátor típusú eleme erre az újonnan beszúrt elemre fog mutatni. 


ú Az insert visszatérési értékének használatára mutat példát az alábbi kód- 
részlet: 
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Vagyis készít egy párt a kulccsal és egy értékkel, amelyet az érték típusának 
alapértelmezett konstruktorával állít elő. Ezt beszúrja, majd a visszaadott 
pár első, iterátor típusú elemén keresztül eléri a beszúrt párt, amelynek má- 
sodik, érték típusú elemét adja vissza referencia szerint (mert az ( ] operátor 
referenciával tér vissza). Vagyis, ha az adott kulccsal rendelkező elem már 
benne van a tárolóban, akkor annak az értékére kapunk referenciát, ha pedig 
nem, akkor beszúrjuk a megadott kulcsot egy alapértelmezett értékkel, és ar- 
ra kapunk referenciát. 

A multimapnél az [ ] operátor nem áll rendelkezésünkre, és az insert visz- 
szatérési értéke a beszúrt elemre mutató iterátor. Az alábbi példánkban 
árukról tárolunk adatokat, nevezetesen, hogy hol helyezkednek el. A csokolá- 
dék a cukorkákkal együtt az egyes pultnál, a tej a hűtőben, illetve a csokoládé 
a pénztár közelében lévő négyes pultnál is megtalálható. 
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E ESÉSE STKÜÜBŐS 





Ha szeretnénk kiíratni, hogy hol található csokoládé, vagyis hogy a multi- 
map-ben egy kulcshoz milyen elemek tartoznak, a lower bound és az upper. 
bound tagfüggvényeket használhatjuk: 7 





A törlést végző függvények az asszociatív tárolókra jellemzően void visszaté- 
rési értékűek, és természetesen érvénytelenítik a törölt elem iterátorát. Ezért 
figyelnünk kell arra, hogy ne léptessük az érvénytelen iterátort. Tegyük fel, 
hogy az egyes pultot eltávolították a boltból, így törölnünk kell minden olyan 
árut a nyilvántartásból, amely az egyes pulton volt. Kézenfekvő, de rossz meg- 
oldás az alábbi: 





Mivel a map-ben és a multimap-ben csak kulcs alapján tudunk keresni, a pult 
pedig jelen esetben az értékben található, az egyetlen megoldás, hogy végig- 
iterálunk a tárolón, és ha egyezik az érték a törlendővel, akkor azt az elemet 
töröljük. A fenti példában is ezt tesszük, de az erase függvény érvényteleníti 
az it iterátort, és a ciklus következő lefutása elején kiértékelődik a ttit kife- 
jezés, ami így futási idejű hibához vezet, és mi talán némi nosztalgiával gon- 
dolunk vissza a szekvenciális tárolókra, ahol az erase tagfüggvény a követke- 
ző érvényes iterátort adta vissza. A hatékonyság miatt az asszociatív tárolók- 
nál nincs visszatérési érték, ezért más megoldást kell keresnünk: az alábbi 
kódrészletben még a törlés előtt képezzük a következő iterátort. 
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12.4.3. Állandó és változó méretű bittömbök 


Ha biteket szeretnénk tárolni, akkor nincs más dolgunk, mint az eddigi táro- 
lók bármelyikét bool értékre példányosítani. Ekkor ugyan egy bájton fog egy 
bit tárolódni, viszont a szokásos iterátorinterfész is a rendelkezésünkre áll. 

Az STL két, kifejezetten bitek tárolására kihegyezett osztályt bocsát ren. 
delkezésünkre, amelyek egyike sem tároló a szó STL értelmében, mivel nem 
teljesítik a tárolókkal szemben elvárt összes követelményt. Ezek az osztályok 
a bithalmazok (bitset) és a vectorcbool:. 


A bithalmazok fordítási időben meghatározott méretű bittömbsablonok, 
amelyeknek egyetlen sablonparamétere a bithalmaz mérete. Egyáltalán nem 
támogatják az iterátoros interfészt. A konstruktoron keresztül a bithalmazo- 
kat mind egész típusok, mind sztringek alapján létrehozhatjuk. Az első eset- 
ben az egész szám bináris értéke lesz a bithalmaz kezdőértéke, a másik eset- 
ben a sztringben megadott bináris szám (például "01000101"). A bithalmazok 
fontosabb műveletei az alábbiak: 

e — operator /( J: visszaad egy referenciát az adott pozícióban szereplő bitre, 

e — set: az összes bitet egyre állítja, 

e reset: az összes bitet nullára állítja, 

e test: ellenőrzi, hogy a megadott pozícióban lévő bit egyes-e, 

e any: igaz, ha legalább egy darab egyes van a bithalmazban, 

e none: igaz, ha egyetlen egyes sincs a bithalmazban, 


e  /flip: invertálja a biteket az egész bithalmazra, vagy a megadott pozí- 
cióban, 


e — bitműveletek: "—, [-, g-, ccz, 557, cc, 55, - bitoperátorok támogatása, 
e — count: a bithalmaz mérete, 
e — összehasonlítás: ——, !-, 


s — konverziók: to. string, to. ulong. 


A következő példa megszámolja az egyeseket és a nullákat egy bithalmazban. 








—— ,—,———,——— e EE EAN STU tárotóle 
A vector cbool? specializáció, vagyis nem olyan vektor, ú 
tékeket tartalmaz. Ilyen szempontból a vectorcbools érsmdg tése konst: 
rukció, nincs ugyanis értelmezve rá a bool tp- $v/0] kifejezés, a vissza. mg jú 
iterátor nem igazi véletlen hozzáférésű iterátor, vagyis sem tárolónak, : s 
vektornak nem mondhatjuk. Ráadásul az sem igaz, hogy bool értékeket tárd 
egy belső tömörített formában, biteken tárolja az értékeket. Mindezért a [10 
irodalom kifejezetten ellenjavallja a vectorcbools használatát. Egy biztos: 
vector sablon specializációja helyett jobb lett volna más nevet választani és 
nek a dinamikus méretű bittömbnek. 

A belső adatszerkezet miatt az elfoglalt memóriaméret ki. i 
egy tárolót bool típussal példányosítottunk volna, CEST ja RÉS 
lassabbak. Mivel a Ct-4-ban a legkisebb címezhető memóriaméret a bájt, 
ezért bitre nem létezik referencia. Vagyis a visszaadott bitreferenciák olyan 
objektumok, amelyek kiveszik a hivatkozott bitet az adatreprezentációból, és 
visszaírják az esetleges változást. É 

Ez a referenciaobjektum az alábbi műveleteket támogatja: 


e  flip: invertálja a bitet, 

e operator —; a bitnek értékül ad egy bool értéket, 
e — bool konverziós operátor, 

e operator —: a bit negáltjával tér vissza. 


A vectorábool: a vektorhoz képest a flip tagfüggvényt biztosítja, amely a táro- 
ló összes bitjét invertálja. 





Feladat: Írjunk olyan programot, amely egy bináris vektorban minden egymás után következő 
őt egyes után beszúr egy nullát." 
Megoldás 


Először létrehozzuk és inicializáljuk a bináris vektort néhány bájtot bináris 
számmá alakítva. Utána a szokásos módon íratjuk a tároló tartalmát: 





4 Ez a számítógép-hálózatok adatkapcsolati rétegében alkalmazott bitbeszúrás öszes 
dik arról, hogy a két oldalán egy-egy nullával szegélyezett hat sorfolytonos egyest tar- 
talmazó, keretező bitsorozat ne forduljon elő az átviendő bitfolyamban. 
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12. fejezet: Bevezetés a Css szabványos sablonkönyvtárába 





Ezek után végigiterálunk a vektoron, és beszúrjuk a nullákat a megfelelő helyre: 








unsigned countsO; $ ü HAN ZT 
sak Törés iterator itspacket.beginO it! 
 1fCit—false) I ; 
1 fálsi sTe bye 
— count-0; sz § úgegetitska 
3 eg 4 , 
else § LEN 
FRGZZÉT VSZ És 
a4count; a ELESÉS 






FÉGHUNE szzi 5) ; 2 j 
£ 


it z páckezinsertésrit0; // Amegnövelt it elé beszúrju 
count — 0; 5 





A beszúrás művelete igényelhet némi magyarázatot. Az insert tagfüggvény a 
paraméterként megadott iterátor elé szúrja be a megadott elemet. Vagyis, ha 
megvan az ötödik egyes pozíciója, akkor még léptetnünk kell egyet az iteráto- 
ron, és utána végezhetjük el a beszúrást. A beszúrás ugyanakkor érvényteleníti 
a következő elemet, vagyis az iterátorunk aktuális pozícióját. Ezért az insert 
tagfüggvény visszatérési értékét használjuk, amely nem más, mint az újonnan 
beszúrt nulla pozíciója. 


12.4.4. A tárolók műveleteinek összehasonlítása 


Ebben a részben az adott feladathoz megfelelő tároló kiválasztásához szeret- 
nénk segítséget nyújtani. Ebben főleg saját tapasztalatainkra és a [4](91(10] 
irodalmakra támaszkodunk. 

Elsőként tekintsük át a tárolók általános tulajdonságait az 1. táblázatban. 

A Cs4 szabvány nem definiálja az egyes tárolókhoz tartozó adatstruktú- 
rát. Nem adja meg, hogy a list tárolót kétszeresen láncolt listaként kell imp- 
lementálni. Megadja ugyanakkor, hogy a tároló adott művelete (például a be- 
szúrás) nagyságrendileg mennyi elemi műveletet hajt végre a tartalmazott 
objektumokon. 

Vegyünk egy vektort, amely n elemet tartalmaz, és tegyük fel, hogy sze- 
retnénk beszúrni az n-1.-et. Ha az új elemet a vektor elejére szúrjuk be, ak- 
kor n elemet eggyel jobbra kell csúsztatni. Egy elem jobbra csúsztatásának 
ideje független attól, mennyi elem van a vektorban, valamilyen állandó, amit 
nem fejtünk ki bővebben. Vagyis a beszúrás ideje konst:"n-tkonst:, ahol az első 
konstans az elcsúsztatás költsége, a második a beszúrásé. 


358 








S E RERÉZKESTÉKÉK 














fe SE ZEN , § Ta att 
a Bo.2!8i : 8. 
sz $§ ]§889]88 $6 s8£ 
É- $.lzZ8l85E 3 39838 
hőt S-A4g piti Hi 9.§ 8 
ki 3sS]9g9Í 652 v -it-ár-tt 
a álsz sSzis8őea 8 3288 
dá a 8 
9 s a d a az g 
É-i 8 ssal 16 4 ú éz 
Fi 3 sag) 9 úg s£4 
B 2 Nr ési $sg 3 S. 9. 
K-i "a SAS] g Hi 3238 
A 4a]Ss8]: 2 a aza 
ki 4á]2sSz IS889 Fi 8488 
8. 2]:8 ERETT 
sz 288188 Bs 
et ga 98 s -j 08 
Ét GB, salt [1 - 9 kh 
bi -ú Hon]dsg a a: ti 
sz K-i $s5SÍgs65 :A Asag 
gizi K3j ASZ2ZI]289 a 8298 
43 őt 
He--i vá 
8..al ég : 8 
zi 588]8és BsEZ 
2 á28]as k- 9938 
ő $ lásálésE B JÁZÁS 
s 8 J$s8]888 ki 2228 
gizi 8 Sa 8 ég zi 82835 
a 8. ő 
e. , a sú Fi] 
96 sg gi Úsz) 5) 
o 8 z Et út 
$ 3 
§8 6; 2. f) $9885. 
as [8 18 ése A ÉSresz 
$s8 a Z lt ét za áz: Bag 
2 8:a 6) s) S 8 [z) R28SáSS 
s sas 
5 : a 
3 ]88 É § 
j 23 348 919 p- 
B 38 Jás8 ES slséöe 
Rem 18 Já8 1388 á8 Járz5 
8 zi krt-i 98 s a ma 9: 
"ss 5) 5.a á8s Hz g5) 84á895 
ő A z. 
De bp ri ag 
9 o CT kt 
EM adog 3 5.8 
6 $548.5 8 -] 
$§a iz 3b82áa 82 
828 8 3ágas§ gs 
30ot "9 a gi go a a 
É-i a a53amy 3 
as. Es Bg54 99 Eléri 
[átt "1 £ 8 sel K-i. 820 Hoi 
859 ég ei 828 38l]s 8 
HOS (8 ás BSA SBS]a Ch 
dá [8 [82 [[ágsás$ola 88 
2 
ki ú o 
ag 2 A az 
3 ési [zi gő 888 
63) FI) B] 
S s k 82 Sá A 
9 áz 26 £ 28 388 
Fi szg lis; 4 g ag [dab 
a 2 ER: 83. lássa 
98 £ i 88 S88s [3588 
47 Fi 5-i -lt-i Ég 3888 
A § a Sá ]8s588 
AH Bi FH eléri ; 
a 8 bi Pt sz Rá9]8- 








1. táblázat, A szabványos tárolók általános tulajdonságai 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 


Ha n kellően naggyá válik, a konstansok nem számítanak. (Sőt, ha n többféle 
kitevővel szerepelne egy polinomban, akkor bizonyos elemszám felett csak n 
legnagyobb hatványa lenne domináns.) Minderre úgy gondolhatunk, hogy az 
elvégzendő elemi műveletek ideje a vektor elejére történő beszúrás esetén n 
nagyságrendjében van. Ezt úgy is mondhatjuk, hogy a vektor elejére történő 
beszúrás O(n) (,ordo n") komplexitású, vagy másképpen lineáris komplexitá. 
sú."9 Vagyis, ha egy vektorba tetszőleges helyre beszúrunk egy elemet, akkor 
ennek ideje legrosszabb esetben O(n), ha az elemet a vektor elejére szúrtuk be. 
Átlagban viszont ennek a fele, de mivel a konstansokat elhanyagoljuk, ez is I. 
neáris idejű. Vagyis kétféle komplexitást számolhatunk: a legrosszabb esetre 
vonatkoztatva, illetve az átlagos esetre — jelen esetben ez megegyezik. 

A vektor végére történő beszúrás konstans komplexitású, amit 0(19-gyel 
jelölünk, persze ez csak akkor ennyi, ha nem kell újrafoglalni a memóriát. Új- 
rafoglaláskor ugyanis le kell másolni mind az n elemet az újrafoglalt memó- 
riatartományba, ami lineáris komplexitású. Ez azonban csak nagyon ritkán 
történik, átlagban elhanyagolható. Amikor csak bizonyos műveletszám fölött 
számolt átlagra érvényes a megadott komplexitás, amely a legrosszabb esetet 
veszi alapul, akkor amortizált komplexitásról beszélünk. Így a vektor vé- 
gére történő beszúrás amortizált konstans idejű. 

A fentiekkel nem szeretnénk azt hangsúlyozni, hogy teljesen mindegy, hogy 
egy művelet egységnyi vagy feleannyi ideig tart. Ez egyáltalán nem mindegy, 
sőt, a konstans tényezők nagyban befolyásolhatják programunk használható- 
ságát. A komplexitás fent bevezetett elemzése azonban nem megy bele ilyen 
részletekbe, sokkal durvább felbontásról ad tájékoztatást, amely kis elem- 
számok esetén sokszor nem is érvényesül: ott ugyanis még az n-nel egy nagy- 
ságrendben vannak a konstansok, és polinom komplexitás esetén az alacso- 
nyabb fokszámú tagok is sokat számítanak. Ilyenkor a komplexitásnak ez a 
leírása nem feltétlenül mérvadó, az egyes elemi műveletek számát kell meg- 
vizsgálnunk, vagy méréseket kell végeznünk (esetleg interneten, illetve szak- 
irodalomban utánanéznünk) a konstansok és alacsonyabb rendű tagok ará- 
nyainak tisztázása végett. Ráadásul az egyes műveletek gyakorisága, kötött 
sorrendje is számíthat. A 12.1.8. Algoritmusok fejezet Rendezett vektor rész 
rendezett vektora ilyen esetben jelent meg az asszociatív tárolók alternatívá- 
jaként: a beszúrás jellegű műveletek elváltak a kereséstől, valamint a lapke- 
zelésű virtuális tár nagyságrendileg befolyásolhatja a konstansokat. 

A továbbiakban a fent bevezetett komplexitást felhasználva fogunk tájé- 
koztató információt közölni az egyes műveletek idejéről, eközben feltételezzük, 
hogy a tároló az adott művelet végzésének pillanatában na elemet tartalmaz. 


A 2. táblázat az általános, minden tárolóra érvényes műveletek komplexi- 
tását foglalja össze. 





" Hangsúlyozzuk, hogy ez elemi műveletnek a tároló elemein végzett műveletet értjük. Ha 


a vektorok elemei n elemű vektorok, akkor a léptetés nem konstans, hanem 0(n). Vagyis 
a komplexitás O(n?). 
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12.4. STL tárolók" 
Za GEKKO E EEEN E Tee esz eli zt irvtsestosszásatttó 














alapértelmezett konstruktor hívása konstans 
másolókonstruktor hívása lineáris 
jterátorlekérdezés: konstans 
begin, end, rbegin, rend 

összehasonlítás: — —, 1, c 2, cz oz lineáris 
értékadás: - lineáris 
méret lekérdezése: konstans 


size, max size, empty 





adatszerkezet kicserélése: swap konstans 
FENN eESENEEENENENZZZZENZe—————gge e MR 
2. táblázat. Az általános tárolóműveletek komplexitása 


Az egyes tárolókra jellemző komplexitást, illetve műveletszámot a 3. táblázat 
tartalmazza. Itt jegyezzük meg, hogy az iterátorok léptetését, illetve két 
iterátor közötti távolságot az advance és a distance sablonfüggvények végzik, 
amelyek másképpen példányosulnak véletlen hozzáférésű iterátorokra és a 
többi iterátorkategóriára. Mivel minden algoritmus és tároló ezeket a függvé- 
nyeket használja, az iterátor léptetése k pozícióval a véletlen hozzáférésű 
iterátorok esetén konstans, míg a többi iterátorkategóriára k-nak lineáris 
függvénye. Hasonló mondható el két iterátor távolságának meghatározásáról. 

Természetesen nem adhatunk általános receptet a tárolóválasztásra 
minden egyes feladat esetén. Általánosságban nem megkerülhető a jelen feje- 
zet táblázatainak módszeres áttanulmányozása, a feladat tárolóhozzáférései- 
nek elemzése, akár mérések elvégzése ez utóbbi megállapítására. Figyelembe 
kell vennünk, hogy léteznek széles körben elterjedt, de nem szabványos STL 
tárolók is, amelyeket röviden a 12.4.5. Nem szabványos tárolók fejezet tár- 
gyal. Nagyon speciális esetben saját STL-kompatibilis tárolót kell készíte- 
nünk, amihez például [9] ad útmutatást. A 3. táblázatban felsorolunk néhány 
szempontot, amelyek segítségünkre lehetnek egy adott feladathoz. j 

A folytonos memóriaterületen elhelyezkedő tárolók dgotatáát s 
memory containers) folyamatos memóriaterületen tárolják az elemeiket. bek 
beszúráskor, illetve törléskor az elemeket léptetni kell. Ez befolyásolja he. - 
jesítményt, és a másolás során az egyes elemek kivételt is RE sé 
tárolók a vector, a degue és a 12.5. Szövegkezelés fejezetben sén fi Bi 
string. Ha gyors beszúrást vagy törlést szeretnénk, nem célszerű ezeket a 
rolókat használni, 
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12.4. STL tárolók" 
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3. táblázat. Az egyes műveletek komplexitása vagy műveletszáma 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 





12.4.5. Nem szabványos tárolók 


Számos STL verzió támogat olyan tárolókat, amelyek nem a szabvány részei, 
Ezek közül a legfontosabbak a hasítótábla-alapú asszociatív tárolók, a hash set 
és a hash multiset, illetve a hash map és a hash multimap. Ezek a tárolók 
azért maradtak ki a szabványból, mert túl későn kerültek a szabványosítási 
bizottság elé, Valószínűsíthető, hogy a következő szabvány részei lesznek, de 
ez természetesen nem garantálható. Mivel nincs egyeduralkodó szabvány, az 
implementációk eltérnek. 

A Dinkumware hash-tárolók az stdext névtérben találhatók, Ezeket fel. 
használva a halmaz bevezető példája a 12.1.1. Tárolók fejezet Halmazok 
részben hash. set-re is működik, ha kicseréljük a set-et hash set-re, és hozzá- 
adjuk a using namespace stdex névtérhasználatot, Hasonló a helyzet a /2.1.1, 
Tárolók fejezet Asszociatív tömb rész mapet tartalmazó példájával, 

Komolyabb felhasználás esetén azonban adódnak különbségek mind a bi- 
náris fát alkalmazó és a hash alapú asszociatív tárolók, mind az egyes imp- 
lementációk között, Például az alapértelmezett hasítófüggyény csak egész tí- 
pusokra használható (az SGI által alkalmazott hasítófüggvény kicsit általá- 
nosabb, például char" típusra ís működik). A nem szabványos tárolók részle- 
tes tárgyalása meghaladja könyvünk kereteit, a következő szabvány valószí- 
nűsíthetően egységesíti a hasítótábla-alapú tárolók használatát, 


12.5. Szövegkezelés 


A C programozási nyelv egyik legnagyobb problémája a sztringkezelés. A szab- 
ványos C sztringkezelő függvények többsége nem támogatja a buffer méreté- 
nek ellenőrzését, így számos C program válik sebezhetővé buffertúlesordulás 
miatt. A Ctt-ban a sztringek osztályként is implementálhatóak, amelyek az 
egységbezárás, az adatrejtés és az automatikus inicializálás miatt biztonsá- 
gossá tehetők. 





Útmutató: Cs nyelven, ha csak lehet, kerüljük a C stílusú sztringek használatát! 


A C44 szabványos könyvtárában a nemzetközi fejlesztés támogatása végett a 
sztringek ís sablonként jelennek meg: a basic string specializációi, Az STL két 
specializációt bocsát rendelkezésre típusdefinícióként: a string a basic string 
char típussal vett specializációja, míg a wstring esetén wchar t a sablonpa- 
raméter (a wchar t típusról a 12.6. Magyar nyelvű fejlesztés fejezetben talá- 


lunk bővebb információt). Egy lehetséges implementációt az alábbi kódrészlet 
szemléltet. 








A basic string sablonnak további sablonparamétereket is megadhatunk, ame- 
lyeknek alapértelmezett értékeit az STL automatikusan a rendelkezésünkre 
bocsátja, ezért nem kellett kiírnunk a fenti kódrészletben (az alapértelmezett 
sablonparamétereket a 11.2.3. Alapértelmezett sablonparaméterek fejezet tár- 
gyalta). Ezek közül a legfontosabb char traits típusú sablon, amely a karak- 
terjellemzőket (character traits) zárja egységbe. Ez a sablon adja meg a 
sztring osztályok (és számos be- és kimenetiadatfolyam-sablon) számára az 
alapvető típusdefiníciókat, a másolás, értékadás, keresés, méretszámítás mű. 
veleteit és az állományvége-jelet (EOF). 

A fenti típusokat a string állományban találjuk. A sztring osztályok egy- 
ven szekvenciális tárolók: véletlen hozzáférésű iterátorokkal is manipulálhat- 
juk tartalmukat, és alkalmazhatjuk rá az algoritmusokat. 

A szabvány a sztring osztályok esetén is csak a műveleteket definiálja, 
azok megvalósítását nem, így az egyes implementációk belsejükben eltérhet- 
nek egymástól. A jelenlegi sztring típusok nem támogatják a reguláris kifeje- 
zéseket, ezek várhatóan a következő szabvány előírásaiban azonban benne 
lesznek. 


12.5.1. Inicializálás 


Egy sztringet többféleképpen is inicializálhatunk a konstruktorán keresztül. 
Erre mutat példát az alábbi kódrészlet. 


// Létrehoz egy üres stringet 
string s1; 


// c stílusú sztringből inicializál 
string s2("James Bond 007"); 


// Másolókonstruktor: s3 értéke James Bond 007 
string s3(s2); 


. //A megadott indextől inicializál: s4 értéke Bond 007 
string s4(s2,6); 


// A megadott indextől a megadott számú karakterrel 
[/ inicializál: s5 értéke Bond 
. String s5(s2,6,4); 





Inicializálás karaktertömbből. A "NO" nem számít 
Speciális karakternek, benne lesz a sztringben 

char Heat No" "bt tere é 
— string s6(t, sizeof(t)/sizeof(t[0]); tagi 
út v A ; ek Mn 
M/ nicializálás n db karakterrel. Az s7 értéke aaa. ok elle ltek 
[Sing ST aD); jgaságn: ? 
















terátoros inicializálás: s8 értéke: James 
Ng-s8(s2.beginŐ ; s2. begin OrSjszkt sad dlaa sss sKeMzsteszés 
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12. fejezet: Bevezetés a Cst szabványos sablonkönyvtárába 





Kiíratva az egyes sztringeket, az alábbi kimenetet kapjuk (az első sor üres 
sztring): 





A sztring osztálynak nincs olyan konstruktora, amely egy karaktert vár, ezért 
az s7 inicializálásánál alkalmazott konstruktort használhatjuk erre a célra: 





Ez egyben azt is jelenti, hogy nincs automatikus konverzió char típusról 
string típusra. 

Ha széles karaktereket szeretnénk használni, akkor a wstring típus a 
megfelelő választás. Ilyenkor természetesen a string esetén a char típust váró 
konstruktorok wchar t típust várnak. 








12.5.2. Méret és memóriakezelés 


A sztringek a szekvenciális tárolókhoz (12.4.1. pont) hasonlóan folytonos me- 
móriaterületen tárolják az adataikat. Ha a sztringek csak annyi memóriát 
foglalnának, mint amennyi az adott pillanatban szükséges, akkor minden 
egyes beszúrás, hozzáadás új folytonos memóriaterület foglalását eredmé- 
nyezné, ahova át kell másolnunk az eredeti adatokat, és a beszúrt vagy hoz- 
záadott karaktersorozatot. Így ezen műveletek gyorsítása végett a sztringek 
nagyobb memóriaterületet foglalnak le, mint az adataik aktuális mérete. Ezt 
a nagyobb memóriaterületet kapacitásnak (capacity) nevezzük. Vagyis a ka- 
pacitás azon karakterek maximális száma, amelyeket a sztring a belső me- 
mória újrafoglalása nélkül képes tárolni. 


366 





—— — — ee 5. szövegkezelés 


A kapacitást a capacity() tagfüggvénnyel kérdezhetjük le, és a reserve 
1 állítjuk be. Például egy legfeljebb 1500 karakter méretű heg. 
jegyzést tároló sztringet az alábbi módon állíthatunk be úgy, hogy elkerülje 
az újrafoglalást: 


Eddig a sztring osztály teljes mértékben hasonlít a vector tárolóra (21. 
pont). A vectorral ellentétben a sztring ugyanakkor képes lehet szsugorodni". 
Ha paraméter nélkül hívjuk meg a reserve tagfüggvényt, akkor a sztring az 
aktuális adat méretére zsugoríthatja a memóriaterületet. A szabvány ezt nem 
írja elő kötelezően, számos implementáció nem változtatja a sztring kapacitá- 
sát, ha mégis megteszi, az csak a reserve() hívása miatt történhet. 

A sztring méretét két teljesen ekvivalens tagfüggvénnyel kérdezhetjük le: 
az egyik a többi tárolóra is jellemző size(), míg a sztring osztályok esetében a 
length() is rendelkezésünkre áll. A folytonos memóriaterület miatt egy sztring 
nem lehet tetszőlegesen hosszú, az adott architektúra behatárolhatja a 
sztring maximális hosszát. Ha ez mégsem lenne így, akkor a sztring méretét 
tartalmazó változó maximális értéke szab határt. A maximális méret lekérde- 
zésére a max. size() tagfüggvény szolgál. Annak megvizsgálására, hogy egy 
sztring üres-e, az empty() tagfüggvényt érdemes használnunk. 


12.5.3. Alapműveletek 


Ebben a fejezetben az alábbi sztringműveleteket ismertetjük: 


.  Értékadás 

s Összehasonlítás 

e Összefűzés 

e — Részsztring 

s Karakterek és részsztringek keresése 

.  Elemhozzáférés, bejárás 

s Karakterek beszúrása 

s Karakterek törlése 

. Karakterek cseréje 

s  Kisbetűs/nagybetűs átalakítás, kis- és nagybetűket nem megkülön- 


böztető keresés és összehasonlítás 


Inicializálás után a sztringeknek az - operátorral tudunk értéket adni. 
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12. fejezet: Bevezetés a Cr szabványos sablonkönyvtárába 





Az egyenlő operátornak megadhatunk C sztringet, a C44 basic string sablon 
megfelelő specializációját, illetve egyetlen karaktert. Az - operátor helyett 
használhatjuk az assign tagfüggvényt. Ha a sztringnek egy karaktertömböt 
szeretnénk értékül adni, akkor ezt csak a tagfüggvénnyel tehetjük meg: 





Ha meg szeretnénk cserélni két sztring értékét, akkor a swap tagfüggvényt 
érdemes használni, mert az a belső adatreprezentációt figyelembe véve mi- 
nimális másolással dolgozik, így nagyon gyors. 





Két sztring összehasonlítását az ——, !- c, cz, 5, 97 operátorokkal végezhet- 
jük. Az összehasonlítás ábécé szerinti összehasonlítást jelent. Mindegyik ope- 
rátor visszatérési értéke bool. 





A fenti kódrészlet kimenete az alábbi: 





Ha szeretnénk árnyalni az összehasonlítóműveleteket (például két részsztring 


összehasonlítása), akkor a compare függvény különböző túlterheléseit hasz- 
nálhatjuk. 





E e EMNssteázet ts 


compare visszatérési értéke int, a függvény ni - 
ETEK egyenlő, negatív értéket, ha sali kisebb, ÉLTE ab álszmz tssÉ mét 
tér vissza, amikor sall ábécé szerint nagyobb, mint sali, A compare első 
ramétere adja meg a sali sztringben azt a pozíciót, ahonnan el kell kezdeni áz 
összehasonlítást. A második paraméter megadja, hogy az adott pozíciótól 
hány karakter vesz részt az összehasonlításban. A harmadik argumentum- 
ban megadott sal! sztring egy részét kell összehasonlítani a sali sztring ei 
részével, ahol a kezdő pozíciót és az összehasonlítandó karakterek számát Sz 
utolsó két paraméter adja meg. Mivel a két sztring az első két karakteren 
megegyezik, példánkban a compare visszatérési értéke 0. 

Ha azt szeretnénk megvizsgálni, hogy egy sztring eleje megegyezik-e egy 
adott karaktersorozattal, akkor az alábbi megoldást használhatjuk: 








A fenti függvényt a sablonok segítségével alkalmassá tettük arra, hogy tetsző. 


leges sztringtípussal (pl. wstring) is működjön. Felhasználására az alábbi 


kódrészlet mutat példát: 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 





string ur1-("http://ww. google . com") ; 
string prefix("http"); 
coutcx starts with(ur1,prefix); 


wstring wname(L"özv. Baradlayné"); 
wstring wprefix(L"özv."); 
cout cx starts. with(wname, wprefix); 


A fenti esetekben a starts with visszatérési értéke true. Hasonlóképpen imp- 
lementálhatjuk azt a függvényt is, amely megvizsgálja, hogy egy sztring a 
megadott karaktersorozatra végződik-e. 


template c 
class CharType, 
class Traits, 
class Allocator 


s 


bool ends with(const basic string cCharType, Traits, 
Allocator;€§ str, const basic string cCharType, 
Traits, Allocators§ value) 
( 
basic string ccharType, Traits, Allocator;: : size. type 
value size - value.lengthO; 
return (str.compare(str.length() -value. size, value. size, 
ő value) --0); 


A használata megegyezik a starts with sablonnal: 
ends with(Cur],string("com")); // a visszatérési érték true 
Sztringek összefűzésére leggyakrabban a 6, illetve a t— operátorokat használjuk. 


String firstName - "James"; 

String lastName - "Bond"; 

String name z firstName 4 " " 4 lastName; J Bond 
name 4 " 007"; // James Bond 007 ÖNstbt 


Az átjárhatóság a C stílusú sztringek és a C-4-k sztringek között természetes, 
mert a t és a t— operátoroknak létezik olyan túlterhe. 
illetve const char" típust vár (ez wchar t, illetve const wchar.t" típusokat je- 
lent wstring esetén). Ezért kényelmesen írhatjuk az összefűzéseket operáto- 


ros formában, Ha több lehetőségre van szükségünk, mint amennyit az operá- 


torok biztosítanak, akkor az ap, ü 6 4 ; k 
j 2 pend tagfüggvényt haszná . Ha karak- 
tertömbben áll rendelkezésre SRRVÉDY SAFOZINBAH ÉBE 


ae; A 5 a karaktersorozat, akkor azt az alábbi módon 
fűzhetjük egy C-- sztringhez. 


lt verziója, amely char, 
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áng firstName - "James"; 
da TastName - "Bond"; 
ng name - firstName 4 " " 4 lastName; // James Bond 


§ 1788 1007[J-(! "TOO 7; 
name . append(t007, sizeof(t007)/sizeof(t007[0])) ; 






// James Bond 007 


Mivel itt a karaktersorozatot a karaktersorozat elejére mutató pointerrel és a 
karaktersorozat méretével adtuk meg, a "0" karakternek nincs speciális je- 
lentése, az is egy teljes értékű karakter lesz, mint ahogy ezt a string osztály 
hasonló paramétereket váró konstruktoránál láttuk. 

Egy adott sztring részsztringjét a substr tagfüggvénnyel kérdezhetjük le. 


name-" James Bond"; 
cout cc name.substr(6); // Bond 
cout cc name.Substr(0,5); // James 


Az első hívás paramétereként a részsztring kezdetét jelző indexet adjuk át. 
Ilyenkor a substr tagfüggvény az indextől kezdve a sztring végéig terjedő ka- 
raktersorozatot adja vissza egy új sztringben. A második esetben a substr egy 
indexet és az indextől számított karaktersorozat hosszát várja. 

A sztring elemeihez több módon is hozzáférhetünk. Mivel a sztring típusok 
tárolók is egyben, ezért véletlen hozzáférésű iterátorokon keresztül is hozzáfér- 
hetünk az elemekhez. A vector-hoz hasonlóan a sztringek esetében is használ- 
hatjuk a ( ] operátort, amely itt sem ellenőrzi a megadott pozíció érvényességét, 
illetve az at tagfüggvényt, amely elvégzi ezt az ellenőrzést. A konstans [ ] ope- 
rátor kissé eltér a megszokottól: itt az utolsó elem utáni pozíció — amely meg- 
egyezik a sztring hosszával — is érvényes: ezt a tárolót az elemtípus alapértel- 
mezett konstruktorával inicializálta, vagyis char típus esetén a "N0" érték. 
A nem konstans [ ] operátor, illetve az at függvény esetén ez érvénytelen pozí- 
ció. E két utóbbi függvény az adott elemre mutató referenciát ad vissza. Mivel a 
beszúrás és törlés jellegű műveletek megváltoztatják a sztring belső felépítését, 
ezek a referenciák érvénytelenné válhatnak az ilyen műveletek után. 

Az elemhozzáférést az alábbi egyszerű kódrészlet illusztrálja: 


String sz "Hallo"; 
S[1]-"et; // sz"Hello" 


S.at(1)dsta"; // sz"Hallo" 
drg :iterátor ít z s.beginO; 
Hitatet; 7/ sz"Hello" 
A sztringek bejárásához megszámoljuk, hány "1 karakter van egy sztringben. 


A számolást kétf eképpen is végrehajthatjuk: felhasználhatjuk a ( ] operá- 
tort vagy az iterátorokat. 
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12. fejezet: Bevezetés a Ctr szabványos sablonkönyvtárába 





SZAláng e terátekőte 7 s.beginO;it 1- s.endO;rrit) 


ARC TA 
Ceti 


J 
cout cz c cc endi; // 2 


Az elemhozzáféréshez hasonlóan a beszúrásnak is kétféle módja van. Az egyik 
az interátorinterfészen keresztüli karakterbeszúrás, amikor egy értéket vagy 
egy iterátortartományt adhatunk meg. A másik lehetőség, amikor a sztring- 
beli pozíciót adjuk meg. Beszúrásra mindkét esetben az insert tagfüggvényt 
használhatjuk. 





Egyetlen karakter beszúrására nincs külön tagfüggvény. Így ha egy karaktert 
szeretnénk beszúrni, egyik megoldásként megadhatjuk sztringként: 
a 


VEN b" 








A másik lehetőség az insert tagfüggvénynek az a túlterhelése, amely a meg- 
adott pozícióba egy megadott számú karaktert szúr be: 





Beszúrás esetén is megadhatjuk a beszúrandó sztringet C, illetve C-t stílus- 
ban, valamint karaktertömbként. 


Karakterek törlésére az erase tagfüggvényt használhatjuk. Ha csak egy po- 


zíciót adunk meg, az erase törli a sztringet a megadott pozíciótól kezdve. A pozí- 
ción kívül megadhatjuk a törlendő karaktersorozat hosszát is. 
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SEEK ZÁS SONKA 





Ha az egész sztringet törölni szeretnénk, három megoldás közül is választha- 
tunk: 





Egy karakter előfordulásának pozícióját a find tagfüggvénnyel kereshetjük 
meg. Ezt széles karakterek esetén az alábbi példa illusztrálja. 





A find visszatérési típusának neve size type. Ha a függvény nem találja a ke- 
resett elemet, egy speciális konstanssal, az npos tagváltozóval tér vissza. Mi- 
vel a size type fordítóról fordítóra különböző lehet, ezért a hordozhatóság ér- 
dekében mindig ezt a típust használjuk a find visszatérési értékének eltáro- 
lására, ne int vagy long típusú változót. Megtörténhet ugyanis, hogy a függ- 
vény npos értékkel tért vissza, de a konverziók miatt a vizsgálatkor nem fog 
teljesülni az egyenlőség. 

Amennyiben nem a sztring elejétől, hanem a végétől számított első elő- 
fordulásra vagyunk kíváncsiak, akkor az rfind tagfüggvényt használhatjuk. 
A függvény a visszaadott pozíciót a sztring elejétől számolja, csak a karakter 
előfordulását keresi a sztring végétől. 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 





Ha ki szeretnénk írni az egyes részdátumokat (hónap nap, illetve nap), akkor 
végig kell keresnünk a szóközöket a sztringben, Ilyenkor nemcsak az első elő. 
fordulásra vagyunk kíváncsiak, hanem az összes többire is. 





A megoldáshoz felhasználjuk, hogy a find tagfüggvénynek megadhatunk egy 
pozíciót is, ahonnan a keresést el kell kezdenie. Így a legutóbb megtalált ka- 
rakter pozícióját megnöveljük eggyel, és onnan folytatjuk a keresést. A prog- 
ram kimenete az alábbi: 





Mivel a keresés által visszaadott aktuális pozíció a szóközök pozíciója, a ki- 
menet szóközökkel kezdődik. A find és rfind függvényekkel nemcsak karakte- 
reket, hanem sztringeket is kereshetünk. A megtalálandó sztring paraméte- 
reket megadhatjuk C, illetve C-4-- stílusban ís, valamint karaktertömbökként. 

Ha nem tudjuk pontosan a dátumban található adatok sorrendjét, és sze- 
retnénk megkeresni a hónap nevét, akkor rá kell keresnünk az első olyan ka- 
rakterre, amely nem szám, nem szóköz és nem pont. Erre használhatjuk a 
find first not of (kb. ,keresd meg az elsőt, amely nincs az alábbiak között") 
tagfüggvényt. Ennek egy karaktersorozatot adhatunk át mind C, mind Crt 


sztringként, és megkeresi az első olyan karakter pozícióját, amely nincs ben- 
ne a megadott sztringben. 





Esetünkben a keresett karakter nem lehet számi ü 
7 jegy, pont vagy szóköz, így 
ezeket szerepeltettük a függvény paramétereként. A szöveg végét a find last 


not of függvénnyel kerestük meg, amel i 
érez lve égett y az első, a paramétersztringben nem 


374 





se Ezeknek a függvényeknek számos túlterhelése létezik: a karakter- 
hadat megadhatjuk C és Ctr sztringekként, karaktertömbökként, de mék 
adhatunk egyetlen karaktert is. Akár egy pozíciót is átadhatunk, ha a kere- 
sést nem a sztring elejéről vagy végéről szeretnénk indítani. 

Ha egy adott részsztringet szeretnénk kicserélni, akkor a replace tagfügg- 
vény különböző túlterhelései állnak rendelkezésünkre. Tekintsük meg az 
alábbi példát! 
nt ("James Bond 00799; 


e(0, sagent.lengthO , "Mata Hart"); 
"sagent cc endi; // Mata Hari 






A replace tagfüggvény első paramétereként azt a pozíciót adjuk át, ahonnan 
kezdjük a cserét, a második paraméterben megadjuk, hogy milyen hosszú ka- 
raktersorozatot szeretnénk kicserélni. A harmadik paraméterként adjuk meg, 
hogy a megadott karaktersorozatot mire szeretnénk lecserélni. Jelen pél- 
dánkban az egész sztringet lecseréltük, így a 0 kezdeti pozíciót adtuk meg, és 
a teljes sztring hosszát. Az utolsó paramétert szokás szerint megadhatjuk C 
és Ct4 stílusban, valamint karaktertömbként. C--t sztring részsztringjét is 
megadhatjuk cserekaraktersorozatként. Nemcsak sztringre cserélhetünk, meg- 
adhatunk egy karaktert, amelynek tetszőleges számú sorozatát is beszúrhat- 
juk. A cseréhez felhasználhatjuk az iterátorinterfészt is: a pozíciót iterátorként 
adjuk meg, illetve iterátortartományt iterátortartományra cserélhetünk. 

Mivel a sztringek a többi tárolóhoz hasonlóan az iterátorinterfészt is 
megvalósítják, ezért alkalmazhatjuk rájuk az algoritmusokat. Sőt, számos 
műveletet így célszerű megvalósítanunk. Csak az angol ábécé karaktereit fel- 
tételezve a C nyelvben használatos toupper és tolower függvényeket használ- 
va nagybetűssé vagy kisbetűssé alakíthatunk egy sztringet: 


d tolower(stringé. str) É 

fűt f ; ú 
transform cstring::iterator, string: :iterator, ANECIREJE EE ESA 
sebe (str. begínÖ; str.endO, str.beginO, tolower); 







regét 
tendetas 





sformestring: :iterator,strini :riterator, intCintbz 
4 (str.beginO, str.endO, str.beginO, toupperdi 


as 





Mivel itt C függvényeket használtunk, ezek a függvények csak hagyományos, 
ggvényeket haszni 1882 tűlterhelései miatt nem 


angol karakterkészletre működnek. A transf. 3 k az exp- 
minden fordítónál működik az implicit példányosítás, ezért megad öv elvi 
licit sablonparamétereket is. A széles karakterek esetét a 12.6.2. é zábőn 
környezetek programozása fejezet Magyar nyelvű szövegfeldolgozás rés 


Vizsgáljuk meg részletesebben. A függvények használata egyszerű: 
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string üstringC"auick broun fox junps over the Tazy dog OUICK BRON 
s FOX JUMPS OVER THE AAZY DÖG 123456789") $ s Ügjérvezzej 
tolower(ustring) ; 

cout cc ustring cc endi; 





A programrészlet a várt kimenetet állítja elő (a hosszú sztringek átnyúlnak a 
következő sorba): 


OUICK BROWN FOX JUMPS OVER THE LAZY DOG OUICK BROWN FOX JUMPS OVER 
THE LAZY DOG 123456789. EÁ átlát s; gi 
auick brown fox jumps over the lazy dog guick brown fox jumps c 

. the lazy dog 123456789 7 szesálvál 4 úszkáló 





Említettük, hogy az összehasonlítást a basic string második sablonparaméte- 
reként megadott char. traits sablon példánya adja meg. Ez alapértelmezésben 
figyelembe veszi a kisbetűk és a nagybetűk közti különbséget. A következő 
összehasonlítófüggvény nem érzékeny a kisbetű/nagybetű különbségekre, mert 
mindent kisbetűvé konvertálunk, és így végezzük el az összehasonlítást: 


Hús case insensítive. compare(string 1hs, string rhs) 





12.5.4. I/O függvények 


Ebben a fejezetben a sztringek és az adatfolyamok kapcsolatát foglaljuk ösz- 
sze. Ez két témát jelent: 


" sztringek beolvasása adatfolyamokba és sztringek beolvasása adatfo- 


lyamokbál, illetve 


" a sztringek mint adatfolyamok. 


982esldági példák alapján láttuk, hogy a sztringekre és az adatfolyamokra lé- 
teznek a szokásos cc és 55 operátorok. Széles karakterek és sztringek esetén 


egy w betűt kell írnunk az eddigi adatfolyamosztályok és -objektumok neve 


elé. Igy beolvasáskor például a wifstream, wistream osztályokat, illetve a wcin 


adatfolyam-osztályokat. 3 
A beolvasást végző operátorra az alábbi kódrészlet mutat példát: 
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tor azonban nemcsak beolvassa a sztringet, hanem fel is dol. K 
részét hogyha a noskipus jelzőbit nincs beállítva az dsíöléatára, 
jisee szóköz jellegű karaktereket a karaktersorozat elejéről nem másolja 
tele a sztringbe. A beolvasás addig folytatódik, amíg a következő feltételek 
valamelyike nem teljesül: 


. A beolvasott karakter szóköz jellegű karakter (ilyen például a szóköz, 
a It és a In karakter). Ilyenkor ez a karakter már nem másolódik a 
sztringbe. Ez a működés megegyezik a C-ből ismert scanf ("48"... JV 
selkedésével. 


e Avbeolvasás elérte az állomány végét. 


e Asztringbe beolvasott karakterek száma elérte bemeneti adatfolyam- 
nak beállított szélességet (pl. cin.with(2)). 


. Avbeolvasás eléri az istring.max size() számú karaktert. 


s A beolvasás közben hiba lépett fel, az adatfolyam good tagfüggvénye 
(pl.: cin.good()) hamissal tér vissza. 


Megjegyezzük, hogy a bemeneti adatfolyam szélességét felhasználhatjuk C 
stílusú sztringek biztonságos beolvasására: 





A szélességgel ugyanis megadhatjuk a beolvasandó karakterek maximális 
számát, amelybe a 55 operátor a lezáró nullát is beleszámolja, így nem írjuk 
túl a rendelkezésre álló buffert. r ói 

A beolvasás során a sztring megoldja a memóriakezelést. Ha a billentyű- 
Zetről olvasunk, a függvény továbbra is soronként olvas, de a sztringbe csak a 
fenti szabályoknak megfelelő karaktersorozatok kerülnek bele. Ha egy sort 
Szeretnénk beolvasni, akkor az 5.1. A szabványos adatfolyamok fejezetben 
már említett módon a getline globális függvényt használhatjuk. A függvény 
használatát az alábbi kódrészlet illusztrálja. 





A függvény az adatfolyam-objektummal tér vissza, amelyet a piára e 
ezelésre is felhasználhatunk. A getline addig olvas, amíg az alábbi 


telek közül valamelyik be nem következik: 
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e Új sor karakter következik. Ilyenkor a függvény az új sor karaktert 
beolvassa az adatfolyamból, de nem adja hozzá a sztringhez. 


e A beolvasás elérte az állomány végét. 
e. A beolvasás eléri az istring.max. size() számú karaktert. 


e A beolvasás közben hiba lépett fel, az adatfolyam good tagfüggvénye 
(pl.: cin.goodO) hamissal tér vissza. 


Állomány esetében teljesen hasonlóan alkalmazhatjuk a getline függvényt: 





A lefordított kódrészlet kimenete az alábbi: 





Amikor a getline által visszaadott adatfolyam állapotát vizsgáljuk, akkor az 
állomány vége esetén sem fut tovább a ciklus. Jól látható, hogy a getline sab- 
lonfüggvény impliciten példányosítható széles sztringekre is. 

A getline sablonfüggvénynek létezik egy olyan túlterhelése, ahol a határo- 
ló karakter nemcsak a sorvége lehet, hanem paraméterként megadhatjuk azt. 
Ha szavanként szeretnénk beolvasni az állományt, akkor megadhatunk szó- 


közt is a sorvége helyett: 





Ekkor szavanként is meg tudjuk jeleníteni az állományt. 








Az adatfolyamok kimenete nemcsak állomány vagy a szabványos kimenet jei 
het, hanem sztring is. Ezt a sztringadatfolyamok teszik lehetővé, amelyek 
5 adatfolyamok, mint a többi, hiszen ezek rendre a basic istream, a 
basic ostream, illetve a basic iostream sablonokból származnak. A Sztn 
adatfolyamokat az sstream állományban található osztályok példányosításá- 
val használhatjuk. A sztringadatfolyam-osztályokat a következő táblázat fog- 
lalja össze: 


istringstream/ wistringstream Bemeneti sztring-adatfolyam, csak olvasható. 
ostringstream/wostringstream Kimeneti sztring-adatfolyam, csak írható. 
stringstream/ wstringstream Sztring-adatfolyam, írható és olvasható. 

4. táblázat. Sztringadatfolyam-osztályok 





A legfontosabb függvény, amelyet a sztringadatfolyam-osztályok hozzátesz- 
nek az adatfolyam funkcionalitásához, az str függvény. 

Ennek két túlterhelése létezik. A paraméter nélküli verzió visszaadja az 
adatfolyam tartalmát egy sztringben, a másik egy sztringet vár paraméter- 
ként, amelyet beállít az adatfolyam tartalmának. Nézzünk erre egy példát! 





Természetesen a , Hello world" kiíratásának számos egyszerűbb módja léte- 

zik, de a sztringadatfolyamok jelentőségét nem is ez a példa adja. Egyik 

hasznos lehetőség, hogy az állományokhoz hasonlóan írhatjuk és olvashatjuk 
akód minimális megváltoztatásával. 
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Az előbbi példánkhoz képest csak az adatfolyam típusát kellett megváltoztat- 
nunk, és el kellett távolítanunk a close hívást, amelyet a kimeneti sztring- 
adatfolyam nem támogat. Az elegánsabb kód miatt a változót is átneveztük. 
Ezek után a sztringadatfolyam tartalma ugyanaz lesz, mint előző példánkban 
az állományé. szik BI: 

A sztring-adatfolyamok biztonságos C--t verziói a C-ből ismert sprintf 
függvénynek: formázottan írhatunk vele sztringekbe a buffertúlcsordulás ve. 
szélye nélkül. Az alábbi kódrészlet bemutatja a formázott írást: 





Természetesen a sztring-adafolyamokat az sscanf függvény helyett is érdemes 
használnunk. Ezek az adatfolyamok hibakeresés szempontjából is hasznosak 
lehetnek, valamint konverziókhoz is felhasználhatjuk őket. Ez utóbbi alkal- 
mazást a következő fejezet mutatja be. 


12.5.5. Szöveges konverziókt 


Egy sztringet C stílusú sztringre kétféleképpen konvertálhatunk. Az első lehe- 
tőség a c. str() tagfüggvény használata, amely egy const char? pointeren keresz- 
tül adja vissza a C stílusú sztringet, természetesen N0" végződéssel. Ilyenkor a 
visszaadott adatterület nem módosítható. 





Ha módosítani is szeretnénk a C stílusú sztring tartalmát, akkor a copy() tag- 
függvényt használjuk, amely átmásolja a sztring osztály által tartalmazott 
karaktersorozatot a megadott bufferba. Fontos, hogy ezúttal nem másolódik 


NO" a bufferben lévő sztring végére, erről nekünk kell gondoskodnunk, ha C 
stílusú sztringként szeretnénk felhasználni. 








tagfüggvény első paramétere az a buffer, amelybe a sztring ál új 
hal Én uaté karaktersorozatot másolni szeretnénk. Mivel a buffernek SINZÉHÚ 
tunk helyet, utolsó paraméterként megadjuk a maximális méretű karakterso- 
rozatot; amelyet ebben a bufferben fogadni tudunk beleszámítva a hozzáfű- 
zendő lezárást. A lezárás hozzáfűzése után teljes értékű C sztringként hasz- 
nálhatjuk a buffert. SzG 

Tulajdonképpen a copy függvény sem C stílusú sztringet adott vissza, 
nekünk kellett gondoskodni a lezárás hozzáfűzéséről. A data() tagfüggvény is 
karaktertömböt ad vissza, vagyis nincs "NO" végződés. Ugyanakkor ezt az 
adatterületet nem alakíthatjuk közvetlenül C stílusú sztringgé, mivel a visz- 
szaadott érték konstans, így az adatterület nem változtatható meg. 

Az előző fejezetben említettük, hogy az ott bemutatott sztringadatfolya- 
mok típuskonverziókra is használhatók. A továbbiakban ismertetjük az egyes 
konverziós függvények egy lehetséges implementációját, és azok használatát. 

Egy tetszőleges típus sztringre való konvertálását az alábbi függvény végzi: 







id tocstring (basic. string cCharType, Traits, Allocators§ dst, 
2003 SourceType src) 


basicostringstream -CharType, Traits, Allocators sstream; 
stream cc Src; 

. if(Isstream) 

"throw bad cast; 


dstssstream.strO; 


A sztringek reprezentálására átvesszük a sztring sablonparamétereit is, hogy 
működjön mind hagyományos, mind széles sztringekre. A konvertálandó vál- 
tozó típusát a SourceType sablonparaméterben vesszük át. Ettől a típustól azt 
várjuk el, hogy implementálja a cc operátort a kimeneti adatfolyamokra. 
A sablonparaméterekkel a függvény felhasználóinak nem kell törődnie, mivel 
impliciten példányosulnak majd. Ezek után létrehozunk egy sztring-adatfo- 
lyamot, és beleírjuk a konvertálandó értéket. Ha eközben valamilyen hiba lé 
pett fel, azt az adatfolyam állapota jelzi. Ekkor kivételt dobunk. Ha nem tör- 
tént hiba, akkor a sztringadatfolyam-objektum tartalmával térünk vissza. 
A függvényt például az alábbi módon használhatjuk: 








(cs, 32); 





5532.4)§ 
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Jól látható, hogy a sablon impliciten példányosul hagyományos És széles 
sztringre, valamint egész és lebegőpontos típusokra. Mivel, ha egy számot 
sztringre konvertálunk, annak sikerülnie kell, hacsak nincs valami komoly 
baj (például elfogy a memória), ezért a példában nem kezeljük a kivételt. 

A következő sablonfüggvény sztringet konvertál tetszőleges típusra, amely 
implementálja a 22 operátort a bemeneti adatfolyamokra. 





A függvény megoldásai hasonlítanak a to. string függvényben alkalmazott meg- 
oldások értelemszerű módosításaihoz. Ugyanakkor a hibakezelés itt sokkal na- 
gyobb hangsúlyt kap. Ha az adatfolyamból való olvasáskor lép fel a hiba (pél- 
dául már az első karakter rossz), azt az adatfolyam állapotából tudjuk meg. 
Ezért először ezt ellenőrizzük. A másik hibalehetőség, hogy ha az adott típust 
sikerült beolvasni egy adott pozícióig, de utána hibás rész jön. Ezt úgy ellen- 
őrizzük, hogy még egy karaktert olvasunk az adatfolyamból. Ennek jó esetben 
hibás olvasásnak kell lennie, mert elértük az állományvége karaktert. Ha ez 
nem igaz, akkor a 55 operátor nem olvasta végig a karaktersorozatot, vagyis a 


megadott sztring nem felel meg a céltípus elvárásainak. A függvény használa- 
takor figyelnünk kell a kivételre is: 








12.5. Szövegkezelés 
KG a zös si zjn A 





Ha formátumot is szeretnénk megadni, akkor a fenti függvény apróbb módo- 
sításra szorul. 





A különbség csak annyi, hogy átveszünk még egy sablonparamétert, amely az 
10 manipulátort veszi át. Így, ha hexadecimális számot szeretnénk beolvasni, 
akkor az alábbi módon használhatjuk a függvényt (a kivételkezelést újból 
nem részletezve): 


uk függvények testreszabásával a legtöbb konverziós feladatot megold- 
juk. 100 


—— 2 — zést 
"A fejezet általános célú függvényeit a CD mellékleten a string utils.h állomány ssgrurssá 
7a, amely szabadon felhasználható. Bz az állomány tartalmaz olyan függvényeket, KENI 
t ís, melyeket további fejezetekben részletezünk, ugyanakkor sokszor cekésöő 
Bcsek különböző programozási feladatok megoldása során, és használatukhoz nem szt 
§ts a működésük megértése. 














12. fejezet: Bevezetés a Cr szabványos sablonkönyvtárába 


12.6. Magyar nyelvű fejlesztés 


Mivel ma már a számítógép mindenkinek a munkaeszköze, természetes elvá. 
rás, hogy a programok az egyes felhasználók anyanyelvén kommunikáljanak, 
és a felhasználók kulturális sajátosságait is figyelembe vegyék, mint például 
a pénznem, a számformátum vagy a dátumformátum. Ezt a lehetőséget két 
folyamat teremti meg: az internacionalizáció (internationalization) 91 ég a 
honosítás (/ocalization). 

Az internacionalizáció azt jelenti, hogy olyan általános szoftvereket készí. 
tünk, amelyek hozzáigazíthatóak az adott kultúrához és lefordíthatók az 
adott nyelvre. Ennek a lényege, hogy a programozók nem drótoznak be a 
programkódba kultúra- és nyelvspecifikus információt, valamint hogy a prog. 
ram ezen információk megadásával testre szabható legyen. 

A honosítás ezt a testreszabási folyamatot jelenti. Ennek része a program 
szövegeinek lefordítása, de a programot futtató környezet, többek között az 
operációs rendszer felkészítése ugyanúgy ide tartozik. Példaként említhetjük 
a kódlapok feltelepítését, a helyi konvenciók kiválasztását, amelyek tipikusan 
rendszergazdai feladatkörbe tartoznak. 

A nyelvi és kulturális testreszabással kapcsolatos információkat a nyelvi 
környezetek (/ocale) hordozzák. A nyelvi környezet nemcsak a karakterkész- 
letet, vagy az ábécésorrend szabályait tartalmazza, hanem például a szám-, 
idő- és dátumformátumot, a helyi pénznemet. Az alábbi táblázat tartalmazza 
a magyar és összehasonlításképpen az amerikai sajátosságokat. 























Amerikai Magyar 

Karakterkészlet  a—z, A-Z, központozás a—z, A-Z, központozás, 
áéíóöőúüű, ÁÉÍÓÖŐÚÜŰ 

Számformátum 9,999,999.99 9.999.999,99 
Pénznem $42.25 vagy USD 42.25 42 Ft vagy 42 HUF 
Dátum 6/2/2007 2007. 06. 02. 

Saturday, June 02, 2007 2007. június 2. 
Idő 1:05:58 PM 13:05:58 
Ábécésorrend abcd... 


aábccsd... 
SZET TÉÉSTÉE E ő eses eze ELSE őr IRO 


5. táblázat. Az amerikai és a magyar nyelvi környezet néhány sajátossága 


ee ESSEN 
19! Az internacinalizáció gyakori rövidítése azi e Egán 
RA; lőn, Óó á : ével 
kezdődik, amelyet 18 betű követ, és vé 5 amely az angol szó alapján képződött: í 


egy n következik. 
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A táblázatból látható, hogy nemcsak a jól ismert karakterkészletbeli különb- 
ségek jelentik az eltéréseket, hanem a számformátumban az angol nyelvterü- 
leteken tizedespontot használnak, míg Magyarországon (és például Németor- 
szágban) tizedesvesszőt. Nagy számok esetén az elválasztókarakter az Egye- 
sült Államokban vessző, Magyarországon ez pont vagy szóköz. A pénzössze- 
gek kifejezésénél nemcsak a pénznemek jelentenek különbséget, hanem a 
szám és a pénznem sorrendje. Ez a dátumformátumra is igaz: nemcsak a 
nyelvi különbségek jelentik a problémát, hanem az egyes elemek sorrendje is. 
Az időformátumban is koncepcióbeli különbségeket látunk, akárcsak a ma- 
gyar ábécé kétjegyű betűinél, az ábécérend pedig az ékezetes karakterek mi- 
att elég sok helyen eltér. 

A nyelvi környezeteket a modern operációs rendszerek már alapértelme- 
zésben tartalmazzák, esetleg külön letölthető komponensként, de minden- 
képp rendelkezésre állnak.192 

A Cst Szabványos Könyvtár lehetővé teszi az operációs rendszer által 
támogatott nyelvi környezetek hordozható felhasználását és készítését. Eb- 
ben a fejezetben a magyar nyelvű Ct- fejlesztésre koncentrálva bemutatjuk a 
Cr szabványos lehetőségeit a nemzetközi feljesztés támogatására. Az ASCII 
karakterkódolásból kiindulva röviden bemutatjuk a Unicode szabvány szá- 
munkra fontos elemeit és C-t-- megvalósításukat. Ismertetjük a nyelvi kör- 
nyezetek felépítését és használatát, az arculatok kezelését, a szabványos ar- 
culatokat, valamint az új, illetve leszármazott arculatok készítésének módját. 
Végül a magyar nyelvű szövegfeldolgozás néhány fontosabb műveletét mutat- 
juk be. Mindeközben számos gyakran előforduló feladatra adunk megoldást a 
nyelvi környezetek újonnan megismert szolgáltatásainak segítségével. 


12.6.1. A szabványos nemzetközi karakterkészlet 
A hagyományos karakterkódolások 


A karakterkódolást hagyományosan az American Standard Code for Informa- 
tion Interchange (ASCII — kb. az információcsere szabványos amerikai kódja) 
írta elő, amely főként az angol nyelvet vette figyelembe. Ez a hétbites kódolás 
128 karaktert tartalmaz, ebből 33 nem nyomtatható, többségében manapság 
már nem használatos vezérlőkaraktereket tartalmaz. Alapértelmezésben C/Ct-t 
Programjainkban ezt a kódolást használjuk: a char típus tulajdonképpen egy 
egész változó, amely ezt a kódot tartalmazza. Az ASCII kódolásra igazak azok a 
feltételek, amelyeket a C programozás során megszoktunk: 


1. A nulla ASCII kód nem kódja felhasználandó karakternek, vagyis 
nem fordul elő a sztringben, a sztring végét jelzi. 
NNNÉE S ette ze da j 
"2 Unix/lánux és Linux operációs rendszereken a locale -a paranccsal Jiejáátat hált j 
rendelkezésre álló nyelvi környezeteket. Windows alatt ez a verziónként változó grafikus 


felületen, illetve a CD mellékleten forráskóddal együtt található locale.exe segédprog- 
rammal lehetséges. 
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2. A számjegyek egymás után helyezkednek el. 
3. A nagybetűk és a kisbetűk is sorfolytonosan vannak kódolva, 


4. Betűk és számok esetén az angol ábécében előrébb álló karakter 
ASCII kódja kisebb." 


Az alábbi C nyelvű példákban megmutatjuk a fenti feltételek szokásos ki. 
használását. Elsőként megvizsgáljuk, hogy a ch változóban tárolt karakter 
szám-e. Ha igen, a számjegyet egésszé alakítjuk. Ha nem számjegy, hanem 
kisbetű, akkor nagybetűvé alakítjuk. Ha nagybetű, akkor kisbetűvé alakítjuk, 
Ha egyik sem a fentiek közül, akkor megállapítjuk, hogy speciális karakter. 


// ch számjegy (2. feltétel) 

if(ch 5-"0" 8 ch cz "9") 

í 
// számjegyet egésszé alakít (2. feltétel) 
value z ch-"0"; 
printf(CDigit: XdNn" , value) ; 


J 

// ch kisbetű (3. feltétel): 

else if( ch 5- "a" 4 ch cz "z") 

18 
printf("Lower case letter: Xcin" , ch); 
// kisbetűről nagybetűre (3. feltétel): 
printf("upper case letter: Xcin",ch-"a!tá"a!); 


// ch nagybetű (3. feltétel): 

else if( ch 5— "A" 84 ch cz "zZ") 

1 
printf("upper case letter: gcin",ch); 
// Nagybetűről kisbetűre (3. feltétel): 
printf("Lower case letter: xon" ,ch-TAT4 at); 


ti 
Asia // ch speciális karakter, lehet, hogy nem nyomtatható 
1 printf("special character, maybe not printing: Xcin", ch); 








na: Megjegyezzük, hogy az ASCII által biztosított sorrend sem teljesen felel meg az angol 
ábécé követelményeinek, mivel például nevek rendezése esetén a nagybetűk megelőzik a 
kisbetűket. A helyes sorrend: Maradona, van der Saar, Zambrotta, míg az ASCII szerinti 
rendezés során Maradona, Zambrotta, van der Saar lesz a sorrend, ugyanis a kisbetűk a 
nagybetűk után következnek. Bá. 


A magyar nyelv szabályai nem egyszerűek a rendezés tekintetében. Elsőként megpróbál- 
juk úgy eldönteni a sorrendet, hogy a hosszú és rövid magánhangzók (a-á, e-é, i-i, 0-ó, ő-ő, 
u-ú, ü-ű) és a kis- és nagybetűk között nem teszünk különbséget. Ha így megegyezik a 
két szó, akkor a kisbetűs alak megelőzi a nagybetűset. Ha így sem tudunk különbséget 
tenni, a rövid magánhangzót tartalmazó szó előrébb lesz az ábécében. A rendezés során a 
kötőjeleket nem kell figyelembe venni. Az ábécében is szereplő kétjegyű betűket egyben kell 
tekinteni a sorrend megállapításakor. További részletek találhatók a [20] irodalomban. 
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12.6. Magyar nyelvű fejlesztés 

F athatóra 2 és a 3. feltételezés következetes kihasználása. A következő 
aljában összehasonlítunk két nulla végű C stílusú sztringet (str! és str2) az 
Tlzé szerinti sorrend alapján. Ebben a példában az 1. és 4. feltételt fogjuk 


kihasználni. 


ú dig fut, míg egyik nem lesz nulla (1. feltétel) 
d TÁKZÉRÁN striCi] é4 str2Cil;itr) 
: / Abécé szerinti összehasonlítás (4. feltétel) 
ifrstrili)] c str2Ii)) 


: printf("alphabetical order:(nésinésn" ,str1,str2); 
it return 0; 


jeg) Tvábécé szerinti összehasonlítás (4. feltétel) 


— else if(strICi] 2 str2li)) 


5 printf("alphabetical order: méstnéstn",str2,str1); 
"return 0; 
VOGY 
; 


// Mindkettő a végére ért? (1. feltétel) 
if(striC(i) s— "90" ég str2fi) -—— "99 


printf("The two strings are identica1.m"); 


1 
.// csak az elsőnek értünk a végére? (1. feltétel) 
. else if(str1Ci)] — "N0" 88 str2[i) !- "409 


printf("Alphabetical order :Nn9ésXn9sMn" ,str1, str2); 
else 


printf("aAlphabetical order :(n9stn9éstn" , str2,st PO 


Ha megnézzük az ASCII karaktereket, 01 láthatjuk, hogy lényegében az oz Ég 
ábécé betűinek használatát teszi lehetővé, bizonyos magyar, német vagy spa- 
nyol karaktereket például nem. Ezért kihasználva, hogy a karaktereket álta- 
lában 8 biten tároljuk, a 128-255-ig terjedő kódokat különböző nemzeti karak- 
terékhisz rendelhetjük. Ezekben a kódolásokban a 0- 127-ig terjedő karakterek 
megfelelnek az ASCII kódoknak, a 128-255-ig terjedő karakterek viszont 
nyelvesoportonként változnak. Ezeket a kódolásokat az ISO/IEC 8859 szab- 
vány tartalmazza, 





04 se m 
Keressünk rá az interneten az ASCII betűszóra 
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A szabvány első része, az IS0 ISO/IEC 8859-1, amelyet Latin-1-nek is rö. 
vidítenek, a nyugat-európai nyelveket támogatja, az ISO/IEC 8859-2, amelyet 
röviden Latin-2-nek is neveznek, tartalmazza a magyar nyelv karaktereit 
is.105 Erre a karakterkódolásra az első két feltétel teljesül, a folytonosság és 
az ábécésorrend már kevésbé. 

Újabb probléma, hogy az egybájtos karakterkészlet nem képes tárolni a 
távol-keleti nyelvek karaktereit. Ezért a nemzeti nyelvek támogatására több- 
bájtos karaktereket kell alkalmaznunk. 


A Unicode szabvány 


A Unicode Konzorcium (Unicode Consortium)195 által felügyelt Unicode szab- 
vány ezekre a problémákra kínál megoldást. A Unicode egy univerzális ka- 
rakterkódolási szabvány, amely különválasztja a karakter megjelenítését, 
azonosítását és kódolását. Egy karaktert egy kódpont (code point) azonosít, 
amely egy egyedi egész szám. A megjelenítés és a betűtípus az adott környe- 
zet feladata, a Unicode nem foglalkozik azzal, hogyan kell kirajzolni például 
egy "á! betűt. A kódpontok leképezése bájtok sorozatára számos módon tör- 
ténhet, erre szintén a Unicode szabvány ad javaslatokat. 


Karakterek azonosítása 


A Unicode szabvány szerint egy karaktert kétféleképpen lehet megadni. Leg- 
több esetben egy Unicode karakterhez egy kódpont tartozik, az azonosítja a 
karaktert. A másik módszer a karakterek kombinálása. Ez azon a koncepción 
alapul, amelyet , repülő ékezeteknek" hívunk: az ó betűt a rövid o és a " össze- 
kombinálásával nyerjük. Esetünkben az 0-t alapkarakternek (base character) 
nevezzük, a " karaktert pedig kombinálókarakternek (combining charac- 
ter).107 Az eredményként létrejött ó betűt összetett karakternek (precom- 
posed/composed/composite character) nevezzük. Az alapkarakterek nem le- 
hetnek összetett karakterek vagy vezérlő-, illetve formázókarakterek. 

Az áttekinthetőség kedvéért a Unicode a kódpontok számtartományát Sí- 
kokra (plane) osztja, amelyek mindegyike 2!" (65536) kódpontból áll. 





0. sík 0000-FFFF Basic Multilingual Plane (BMP) 
1. sík 10000—1FFFF Supplementary Multilingual Plane (SMP) 
2. sík 20000-2FFFF Supplementary Ideographic Plane (SIP) 





105 Ezek a karakterkódolások az 8 3: jé; 
májában jél jész egyes operációs rendszerek alatt kódlapok (codepage) for: 


106 http://www.unicode.. 


"" A kotabinálókarakterek listája letölthető a http./www.unicode.orgfeharts/PDF/U0300-pdf 





3.-13. sík 30000-DFFFF Ezekhez a kódpontokhoz még nem rendel- 


tek karaktereket 





14. sík E0000-EFFFF TÖLE Special-Purpose Plane 
) 


15. sík F0000-FFFFF Private Use Area 
16. sík 100000-10FFFF Private Use Area 


E ee 
6. táblázat. A Unicode síkjai 








A táblázatból látható, hogy a szabvány jelenleg 17 síkot definiál. Vannak 
olyan tartományok, amelyekhez egyelőre még nem rendeltek karaktereket, 
sőt, olyan síkokat is találunk, amelyeket saját céljainknak megfelelően hasz- 
nálhatunk fel (private use area). Számunkra a legfontosabb a 0. sík, amelyet 
többnyelvű alapsíknak (Basic Multilingual Plane, BMP) nevezünk. Ezen a 
65536 kódpontot felölelő síkon található karakterek a legtöbb nyelvet és 
gyakran használt szimbólumot lefedik. 

Egy síkot úgy tekinthetünk, mint 256 darab hagyományos kódtáblát. A kom- 
patibilitás végett a Unicode szabvány többnyelvű alapsíkjának első kódtáblája, 
vagyis első 256 kódpontja (0x0000-OXOOFF) megegyezik a nyugat-európai nyel- 
veket támogató ISO/IEC 8859-1 szabvánnyal. Ebből az is következik, hogy az 
első 128 karakter megegyezik a hagyományos ASCII kódolással. Néhány ma- 
gyar karakter nem fért bele a többnyelvű alapsík első 256 kódpontjába, ezek a 
latin kiterjesztés (latin extended) tartományban (0x0100-0Ox024F) találhatók. 

A Unicode karaktereket úgy jelöljük, hogy a hexadecimális kódpont elé 
írunk egy Ut előtagot. Ha a többnyelvű alapsík kódpontjaira szeretnénk hi- 
vatkozni, ahhoz elég négy hexadecimális számjegyet használni (U-0000-— 
U4FFFF). Nézzünk erre néhány példát! 

Az A betű ASCII kódja 0x41. Mivel a Unicode kódpontok első 127 karak- 
tere megegyezik az ASCII értékekkel, ezért a Unicode megfelelője U$0041 
lesz. Az Á betű kódja a Latin-1 kódolásban 0xC1. Mivel a Unicode karakterek 
első 256 kódpontja megegyezik a Latin-1 kódolással, a Unicode kódpont 
U400C1. Az alábbi táblázat összefoglalja az angol ábécében nem megtalálha- 
tó magyar ékezetes magánhangzók Unicode kódpontjait. Látható, hogy az 
karakter kódja U0150. Mivel ez a karakter csak a Latin-2-ben volt benne, itt 
már nem működik a kompatibilitás. 











8 U400B1 Á U:0001 
§ U100E9 É U100€9 
; U400ED Í U-00€D 
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U400D3 

















U100F3 301 
ö Paks U100F6 Ö eg U-400D6 
ő U40151 fagott U-10150 
ú Ut0OFA Ú U-r00DA 
ü U-400FC Ü U400DC 
ű U10171 Ű U--0170 


ee... ———Ú—-..——— en 
7. táblázat. Ékezetes magánhangzók Unicode kódpontjai 


Ha felidézzük a kiinduló feltételezéseket, amelyek az ASCII kódolásra igazak 
voltak, azt állapíthatjuk meg, hogy az első feltétel a kódpont reprezentációjá- 
tól függ, de a többi továbbra is csak az angol karakterekre igaz. A fenti táblá- 
zatban kétjegyű kódolású karakterekre teljesül, hogy a kisbetű-—nagybetű tá- 
volság megegyezik az angol ábécé betűi közötti távolsággal, de az ő és ű, illetve 
az Ő és Ű karakterekre már nem. Ezért az ábécé szerinti rendezés és a kisbe- 
tű/nagybetű konverzió szükségszerűen a nyelvi környezetek részét képezik. 


A kódpontok leképezése bájtsorozatokra 


Az előző fejezetben láttuk a Unicode kódpontok elrendezésének struktúráját. 
Ezek után ezeket a kódpontokat le kell képezni valamilyen konkrét reprezentá- 
cióra, vagyis bájtok sorozatára, Az ASCII karakterek esetén egy karaktert egy 
bájton tároltunk, ezt egybájtos karakterkódolásnak (single-byte encoding) 
nevezzük. A Unicode karakterek esetén ez nem lehetséges, más megoldásokat 
kell alkalmaznunk: itt a karakterkódolásokat a Unicode transzformációs 
formátumok (Unicode Transformation Format, UTF) határozzák meg. Ebben 
a fejezetben a 8-bítes (UTF-8) és a 16-bites (UTF-16) transzformációs formá- 
tumokat mutatjuk be. 

Az UTF-8 változó hosszúságú karakterkódolási formátum. Egy karakter 
kódolása 1, 2, 3 vagy 4 bájtot vehet igénybe. Az olyan karakterkódolást, ahol 
az egyes karakterek értéküktől függően egy, két vagy több bájton tárolódnak, 
több-bájtos karakterkódolásnak (multibyte encoding) nevezzük. Vagyis a 
több-bájtos karakterkódolások esetén a karaktersorozatban keverednek az 
egy bájton, illetve több bájton tárolódó karakterek. Ez különösen nehézzé te- 
szi feldolgozásukat, ugyanis egy adott karakter környezete is szükséges az ér- 
telmezéshez. Az UTF-8 karakterkódolás esetén az első bájt első bitjei hatá- 
rozzák meg, hogy az aktuális karaktert hány bájton kódolták. 





0300000000-Ox0000007F 0 XXXXXXX 
0300000080-OxO00007FF 110 xxxxx 10 xxxxxx 
0x00000800-OXOO0OFFFF 1110 xxxx 10 xxxxxx 10 xxxxxx 
0x00010000-OXOOLFFFFF 11110 xxx 10 xxxxxx 10 xxxxxx 


10 xxxxxx 


—— A e 
8. táblázat. Az UTF-8 kódolás 


A fenti táblázat összefoglalja az UTF-8 formátum lényegét. A Unicode kód- 

ntot átalakítjuk bináris számmá, és a tartomány alapján beírjuk a számot 
az x-ek helyére. Látható, hogy az első 128 ASCII karaktert továbbra is egy 
bájton kódoljuk, méghozzá a kompatibilitás miatt az UTF-8 verziójuk meg- 
egyezik a hagyományos kódolással. Az angol ábécében nem található magyar 
karakterek két bájton kódolódnak. A többnyelvű alapsík karakterei legrosz- 
szabb esetben három bájton tárolódnak, és csak a többi, nagyon ritkán hasz- 
nált karakter foglal négy bájtot az UTF-8 transzformációs formátumot alkal- 
mazva. Az UTF-8 esetén is használhatjuk az U40000 karaktert a sztring vé- 
gének jelölésére. 

Tekintsünk meg most néhány példát! A 0x41 ASCII kódú A betű beleesik 
az ASCII tartományba, vagyis ennek UTF-8 kódolása 0x41 lesz. Ezt termé- 
szetesen a táblázat első sora által kijelölt behelyettesítéssel is megkapjuk. Az 
Á betűnek megfelelő kódpont az U1-00C1. Ez binárisan 00011000001. Ezt be- 
helyettesítve a táblázat második sorában található bitmintába a 11000011 
10000001 számot kapjuk. Ez hexadecimálisan 0xC381. 

Az UTF-16 szabvány a többnyelvű alapsík karaktereit egy az egyben képes 
ábrázolni 16 biten. Külön kódolást csak a többi, U4-10000-től U410FFFF-ig ter- 
jedő kódponttartomány tesz szükségessé. Ezeket az alábbi módon kódoljuk: 


. Elsőként kivonunk 0x10000-t a kódpontból. Ekkor egy .0x0000-tól 
Ox9FFFF-ig terjedő tartományt kapunk, amelynek elemeit 20 biten 
tudjuk eltárolni. 


s — Ezt a 20 bites számot felosztjuk az első 10 bitjére és a második 10 bitjére. 


, A magasabb helyiértékű 10 bitet hozzáadjuk a 0xD800 SZETAKAE CET az 
első 10 bit az U--D800 és az UDBFF kódponttartományba képződik le. 


. Az alacsonyabb helyiértékű 10 bitet a 0xDCO0 számhoz ÜKÉKES 
Így a második 10 bit az U4DC0O0-U4DFFF kódponttartományba kép- 
ződik le. 


391 














12. fejezet: Bevezetés a Css szabványos sablonkönyvtárába 





Az így kialakult két 16 bites számot helyettesítőpároknak (surrogate Pair) 
nevezzűk. A pár első, magasabb helyi értékű tagját magas helyettesítőnek 
(high surrogate), az alacsonyabb helyi értékű tagját alacsony helyettesítő. 
nek (low surrogate) hívjuk, Ezek a tartományok jól láthatóan diszjunktak: a 
kétbájtos értékből rögtön lehet tudni, hogy alacsony vagy magas helyettesítőt 
tárol, Fontos továbbá, hogy az U4D800-U4DBFF, és az U4DCOO-U4DFFP 
tartományokban ne legyenek értelmes, a többnyelvű alapsíkban felhasznált 
karakterek. Ezt a feltételt a Unicode szabvány biztosítja; ez a tartomány fog- 
lalt a helyettesítőpárok számára. 

A magyar karakterek kódpontjukként jelennek meg az UTF-16 kódolás- 
ban. Vagyis az A 0x0041-ként, az Á 0x00C1-ként. A helyettesítő karakterek. 
kel való kódolásra a magyar karakterek esetén nincs szükség: mindig két báj. 
ton tárolódnak. 

Érdemes észrevenni, hogy UTF-16 esetén egy csak ASCII karaktereket 
tartalmazó karaktersorozat UTF-16-as kódolása nem lesz azonos az ASCII 
karaktersorozattal, ami az UTF-8 kódolás egy előnyös tulajdonsága. 

A 16 bítes reprezentáció esetén azonban figyelembe kell vennünk az egyes 
mikroprocesszor-architektúráknál 16 bites egész típus reprezentációját. A két- 
bájtos egész típust kétféleképpen lehet tárolni; a nagyobb helyi értékű bájt 
(big endian) vagy a kisebb helyi értékű bájt (little endian) van az alacsonyabb 
memóriacímen. Az Intel processzorok például a little endian csoportba tartoz- 
nak. Vagyis, ha az UTF-16 támogatáshoz igénybe akarjuk venni a processzor 
több-bájtos egészeket támogató műveleteit, akkor óhatatlanul akadnak kü- 
lönbségek az egyes platformok formátumai között. 

A Microsoft platformokon az állomány elején megjelenik egy bájtsor- 
rendjelzés (byte order mark, BOM),!98 amely jelzi, hogy melyik konvenció 
szerint lett elmentve az állomány. A BOM az UTF-16 esetén az UtFEFF kód- 
pont, amely little endian platformon OxFF OxFE, big endian platformon 0xFE 
OxFF alakban jelenik meg. Ezek a szekvenciák nem zavarják a szöveget, 99 és 
sohasem jelennek meg UTF-8-as kódolásnál (a 8. táblázatból ez jól látható). 
Az UTF-8-cal kódolt karaktersorozat elején az U4FEFF UTF-8 kódolása, az 
EF BB BF bájtsorozat jelenik meg, amely ezúttal csak a formátumot jelzi, hí- 
szen 8 biten nincsenek architekturális eltérések. A POSIX platformokon nem 
használják ezeket a bájtsorrendjelzéseket az állományok elején, mert számos 
hagyományt sértene (például a scriptek nem kezdődnének 4! karakterekkel). 











195 A Microsoft platformokon sokszor signature-nek hívják a bájtsorrendjelzést. Ha POSIX 
platformokon ís akarjuk használni az állományt, akkor válasszuk az UTF-8/ Unicode wiíth- 
out signature mentési opciót. 

109 Az USPEFF a szövegben egy nulla szélességű, nem sortörő szóköz (zero width nobreak 
space, ZWNBSP), a fordítottját, az U4FFFE-t a szabvány nem rendeli érvényes karak- 
terhez, hogy a bájtsorrend meghatározható legyen. 
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SSE MágyáryelVŐ föjleéztés 
Unicode adatreprezentáció a Ct$4-ban 


icode adatreprezentációval kapcsolatban két szempontot ki úlán: 
etadáks Az egyik, hogy a CH forráskódot, amely teétalmnák ETELE; 
karaktereket, milyen formátumban fogadja el a fordító. Természetesen itt fő- 
ként csak a sztringekről és a megjegyzésekről van szó, a változók, konstansok, 
típusok és egyéb nyelvi elemek neve továbbra is a szokásos karaktereket tar. 
talmazhatja. A másik, hogy milyen adattípusban tároljuk el a Unicode karakte- 
reket, illetve hogyan adjunk meg Unicode karakter- és sztringkonstansokat. 

Az első kérdésre a válasz nem túl szívderítő. A fordító által elfogadott be- 
meneti formátum, sajnos teljesen fordítófüggő. A C-4- szabvány ugyanis egy- 
általán nem határozza meg a bemeneti formátumot, csak egy köztes formá- 
tumot, amelyet minden fordító a saját bemeneti formátumából készít el. Sze- 
rencsére általában elmondható, hogy az UTF-8 kódolású forrásállományokat 
a legtöbb fordító támogatja. Itt emlékeztetünk arra, hogy a POSIX operációs 
rendszerek nem támogatják a BOM karaktereket, így a hordozhatóság érde- 
kében ne használjuk őket. 

A program belső adatreprezentációját tekintve a Unicode karakterek és 
sztringek esetében már nem elég az egybájtos char típus. Ezért a karakterek 
méretét tekintve megkülönböztetünk szűk (narrow) vagy más néven közön- 
séges (ordinary), illetve széles (wide) karaktert és sztringet. Karakterek ese- 
tén a szűk karaktereket char típusban tároljuk, ez megegyezik a hagyomá- 
nyos ASCII karakterekkel, míg a széles karaktereket a wchar t típus tárolja. 
AC44-ban a wchar t is beépített típus. 

A wchar t típus implementációfüggő: a fordítóra van bízva, hogyan tárolja, 
leggyakrabban két- vagy négybájtos. Külső reprezentáció esetén (például ál- 
lományba írás, programok közti kommunikáció) hatékony karakterkódolási 
eljárást biztosítanak a Unicode transzformációs formátumok, belső adatrep- 
rezentáció szempontjából ez már nem igaz. Mivel a több-bájtos karakterkódo- 
lások (például az UTF-8) esetén nem ragadhatjuk ki az egyes bájtokat a kör- 
nyezetükből, egy adott sztringet csak az elejétől olvashatunk. Ez nem haté- 
kony, hogyha például a sztring végéről szeretnénk indítani egy keresést. 
Ezért a legtöbb fordító egy széles karakterben egy karaktert tárol, illetve egy 
széles karakterben egy karakter van eltárolva. A tárolás formátuma általá- 
ban a karakter Unicode kódpontjának az értéke az adott méretű, előjel nélküli 
egész változóban eltárolva. €. 

A széles karakterkonstansokat nyelvi szinten ugyanúgy adjuk meg, mint 
eddig, csak az L előtagot kell az idézőjel elé írni: 


Eza sztringkonstansokra is igaz: 


EKENEKZENS ERT TAL árvíztűrő tükörfúrógép: Temes erameaamssantbső 
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12.6.2. A nyelvi környezetek programozása" 


Ebben a fejezetben a nyelvi környezetek használatát tárgyaljuk. Röviden át. 
tekintjük a C-beli megoldásokat, majd erre építve rátérünk a C4--beli megva- 
lósításra. 


C-beli nyelvi környezetek 


€-ben a nyelvi környezet beállítását az alábbi program szemlélteti: 


$include cstdio.h: fg 
$include clocale.h: Me 
finclude ctime.h: vi 
include cassert.h: Mg 
$include cstring.h: 


$define BUFF SIZE 255 


int main(void) 


char" strlocs setlocale(LG ALL, "hun"); 

struct tmt localtm; 

timelt now; 

int order; 3 

wchar. t buff[BUFF. SIZE41]; 

Struct Iconv $ plconv; 

wchar.t namel[] - L"Ádám", name2[] - L"Adorján"; 


if( strloc ss NULL) 


Tlékstül 
—— fprintf 
J 








SS MESET SNEK ESTÉS 





A fenti programrészletben először a setlocale függvénnyel beállítjuk a magyar 
nyelvi környezetet. A nyelvi környezetet kategóriánként is beállíthatjuk:!9 

s  Karakterkezelő függvények (LC CTYPE) 

s Numerikus formázás (pl. tizedesvessző) (LC NUMERIC) 

s  Pénzösszeg formázása (LC MONETARY) 

.  Idő- és dátumbeállítások (LC TIME) 

" Ábécé szerinti összehasonlítás (LC. COLLATE) 
Azösszes fenti kategória beállításához az LC. ALL beállítást használhatjuk. 

A nyelvi környezet sikeres beállítása esetén az új nyelvi környezet szöve- 
$es leírását kapjuk vissza a setlocale függvény visszatérési értékeként. Ezek 


"tán a tizedes törtek tizedesvesszővel íródnak ki, a dátumok formátuma, Úg 
napok és hónapok nevei magyarul. Ha pénzösszeget szeretnénk kiíratni, vi 


E ze RRRNNOBB 
10 POSIX Tösts ; 
operációs rendszereken létezik még az LC.MESSAGES beállítás is, amely a cat 


"Pen0), catgets(), catclose() függvényekre van hatással. 
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kor a localeconv függvény által visszaadott struktúra tagjainak felhasználá. 
sával általános pénzösszegkiíró rutint készíthetünk, mely az összes támoga. 
tott nyelvi környezetben létezik. Az ábécé szerinti összehasonlítást a wscoll 
függvény végzi. L8EN 

A program kimenete Windows alatt az alábbi: 





C nyelven az internacionalizációt sokszor makrókkal oldják meg: 


fifdef . UNICODE 
fdefine TCHAR wchar.t 
fdefine T(x) L Hf x 
felse 
fdefine TCHAR char. 
define -T 
"endif 


Az előfordító itt operátora a szóköz nélküli összefűzést jelöli. A fentiek fel- 
használásával az alábbi kód a UNICODE definiálásától függően vagy széles 
vagy közönséges karaktereket használ: 


 TCHAR str[] — TCHeITO9); 


Ezek után a függvényekre is makrókat kell megadnunk: 








Így már az alábbi kódrészlet is működik mindkét esetben: 


Összefoglalva a következőket mondhatjuk a nyelvi környezetek C-beli támo- 
gatásáról: 


e A nyelvi környezetet kategóriánként is állíthatjuk. 
" A nyelvi környezetet globálisan, az egész programra állíthatjuk be. 








AAA Megye nyelvü fejlesztés 
A is függvények. mint például a wprintf figyelemb ; 

ú revestanoróneszten fü hagyj 
. A nemzetközi fejlesztés támogatását makrókkal oldjuk 3 

sztringekből és a függvényekből kétféle verziót koll haszaáttets a 


Nyelvi környezetek Cs5-ban 


A Cr megoldás sok szempontból eltér a C-ben tapasztaltaktól, A nyelvi kör- 

egy objektum tárolja, amelyet beállíthatunk globálisan is, de az 
egyes adatfolyamokhoz is hozzárendelhetünk más és más nyelvi környezetet. 
Míg a C-ben a nyelvi környezet csak egy adatstruktúra, a Ct-t-ban függvé- 
nyek is tartoznak hozzá. 

A Ctt-ban a nyelvi környezetet a locale osztály zárja egységbe, A locale 
külön osztályokban, úgynevezett, arculatokban (facet) tárolja az egyes kate- 
góriáknak megfelelő beállításokat. Egy locale típusú objektum tulajdonkép- 
pen arculatok gyűjteményének tekinthető (32. ábra). 





32. ábra. Nyelvi környezetek és arculatok 
A szabványos arculatok a következő kategóriákba sorolhatók: 


s  karakterkezelő függvények (ctype, codecut) 

s numerikus formázás (num. get, num put, numpunct) 

s — pénzösszeg formázása (money. get, money. put, moneypunct) 
. idő. és dátumbeállítások (time. get, time put) 

s ábécé szerinti összehasonlítás (collate) 


s  üzenetformázás (messages) 
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Az üzenetek tárgyalása meghaladja könyvünk kereteit, további információ a [3] 
irodalomban található. A továbbiakban bemutatjuk a /ocale objektumok haszná. 
latát, majd ismertetünk néhány példát az arculatok használatára vonatkozóan. 

A locale objektum egyik konstruktorának paramétere a nyelvi környezet 
neve, Ha nem sikerül beállítani a megadott nyelvi környezetet, akkor run. 
time error kivételt kapunk. Az alábbi példa illusztrálja a magyar nyelvi kör. 
nyezet beállítását: 





A locale objektumok többféle kontextusban is felhasználhatók. A Ct-t-ban is 
létezik egy globális nyelvi környezet, amelyet a nyelvi környezettől függő ob- 
jektumok (például az adatfolyam-objektumok létrejöttükkor) alapértelmezés: 
ként használnak. A globális nyelvi környezetet a locale::global függvénnyel 
állítjuk be a példában bemutatott módon. Ennek a függvényhívásnak van egy 
másik következménye: a C függvények által használt nyelvi környezet (printf, 
stb.) is átállítódik csakúgy, mintha a setlocale függvényt hívtuk volna 
LC ALL paraméterrel, Arra azonban nincs lehetőségünk, hogy egy C függ- 
vényhívással megváltoztassuk a C-t-t objektumok és függvények által hasz- 
nált nyelvi környezeteket. A C és a C-t nyelvi környezetek a fenti esetet el- 
tekintve függetlenek egymástól. 

A példában bemutatott konstruktor egy sztringet vár. Ez a sztring az 
adott nyelvi környezet nevét jelenti, sajnos minden platformon más és más 
formában. !!! Ugyanakkor van két érték, amelyet a szabvány szerint minden 
platformnak támogatnia kell, Az egyik a "C" másik az üres sztring (""). Ha 
programunknak megfelel az alapértelmezett nyelvi környezet, és nem állí- 
tunk be semmilyen nyelvi környezetet (a könyv példaprogramjainak nagy ré- 





"1 POSIX operációs rendszereken a beállítható értékeket a /ocale -a paranccsal kérdezhetjük 
Ár o Tent operációs rendszerek alatt a CD-mellékleten található focale.c nevű C nyelvű 
program kiírja az összes telepített, illetve támogatott nyelvi környezeteket. A program 
által az első oszlopban megjelenített rövidítéseket a locale könsézüklasában ís átadhatjuk. 
Unix/lánux platformokon szokásos még a "POSIX" beállítás is, amely egy 7 bites angol 
nyelvű környezet, Windows alatt pontot követően megadhatjuk a kódlapot, például "12507. 








————  —,— 2.6 Magyar nyelvű fejlesztés 


ezt tettük), akkor a klasszikus", a C-ben megszokott nyelvi környezet 
alapértelmezett beállítás. Ez a beállítás az ASCII karakterkészletet hasz- 
nálja. A klasszikus nyelvi környezetet a locale:relassic) függvény segítségével 
érhetjük el. Ha a konstruktorban a"C" sztringet adjuk meg, a klasszikus be- 
állítással jön létre a nyelvi környezet. Üres sztring esetén a nyelvi környezet 
az operációs rendszer aktuális beállításai szerint jön létre: 


A locale osztálynak létezik egy alapértelmezett konstruktora is, Ez az aktuá- 
lisan beállított globális nyelvi környezet másolatával inicializálja a nyelvi 
környezetet. Ha nem állítottunk be globális nyelvi környezetet, akkor a 
konstruktor a klasszikus nyelvi környezetet másolja le, 

A nyelvi környezet arculatainak használatához nézzük meg az alábbi fel- 


adatot! 





Feladat: Programunk belső reprezentációként euróban tárolja a pénzösszegeket. Írjunk olyan 
függvényt, amely az adott nyelvi környezetnek megfelelően vagy forintban, vagy euróban adja 
vissza az értéket. Ha nem szeretnénk a nyelvi környezetekkel bajlódni, akkor a függvény hasz- 
nálja automatikusan a globális nyelvi környezetet. 


Megoldás 


A pénzformátumot a moneypunct arculat tárolja, A moneypunct arculat egy sab- 
lonosztály, amelynek egyik paramétere a használt karaktertípus (közönséges 
vagy széles), a másik paramétere, hogy a nemzetközi pénzneveket használja (pl. 
HUP) vagy az egyes országokra jellemzőt (pl. Ft). A moneypunct arculat curr.. 
symbol tagfüggvénye adja meg a pénznemet. Egy adott nyelvi környezethez tar- 
tozó adott típusú arculatot a use. facet sablonfüggvénnyel kérdezhetjük le. 
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működik minden olyan nyelvikörnyezet-beállításra, ahol az 


A fenti függvény 9x $ 
E KAI forint a pénznem. Ellenkező esetben kivételt ka. 


adott országban euró, illetve 


punk. A nyelvi környezetet alapértelmezésben az alapértelmezett konstruk- 
torral inicializáltuk, ezért a globális nyelvi beállítást fogja alapul venni, ha nem 


adunk meg második paramétert: 


. környezet esetén: 6250 7 





Természetesen megadhatjuk a nyelvi környezetet is (Spanyolországban is eu- 
ró a pénznem): 





Jól látható, hogy amíg a bevezetőben bemutatott módon C nyelven makrókkal 
oldottuk meg a sztringek és a függvények szűk és széles belső karakterrepre- 
zentációjának használatát, a Ct-t-ban mindkét esetre sablon áll rendelkezésre 
(jelen esetben a moneypunct arculat), és a fordító a függvények esetén a sablon- 
példányosítás során automatikusan eldönti, hogy melyik verzióra van szükség. 

A fentiekben megnéztük a nyelvi környezetek és a hozzájuk tartozó arcu- 
latok használatát. Most rátérünk az arculatok készítésének tárgyalására, 
amelyhez vegyük szemügyre a nyelvi környezetet megvalósító osztály felépí- 
tését! A locale osztály valamilyen implementációtól függő tömbben (például 
vector, C stílusú tömb) tárolja az arculatokat. Az arculatok egy közös ősosz- 
tályból (/ocale::facet) származnak, amely a locale osztályon belül definiált osz- 
tály (lásd 5.1. A szabványos adatfolyamok fejezet). A locale osztályban talál- 
ható tömb facet típusú. A facet ősosztályt nem példányosíthatjuk és nem má- 
solhatjuk, mert ezek a függvények nem publikusak. Minden leszármazott ar- 
culatnak kell tartalmaznia egy locale::id típusú statikus tagváltozót, amely 
egyértelműen azonosítja az adott arculatot. Ez a tagváltozó nincs benne a fa- 
cet ősosztályban, a leszármazottaknak kell implementálniuk. Ez az azonosító 
akkor kap értéket, amikor először hozzárendeljük egy nyelvi környezethez. 

Ezt a locale osztály konstruktorán keresztül tehetjük meg. Mivel a konst- 
ruktor használja a leszármazottban definiált azonosítót, ezért nem elég egy 
ősosztályt váró konstruktor. Ezért a locale osztály arculatot váró konstruk- 
tora sablonfüggvény, amely minden új leszármazott arculatra elkészül. 


Ez azt jelenti, hogy akárhányszor hozzáadunk egy arculatot a nyelvi környe- 
zethez, egy új példányt kell létrehozni a locale osztályból, Ugyanakkor ennek 
a műveletnek az erőforrás-igénye nem nagy, mivel a nyelvi környezetek adat- 
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tagjairól csak sekély másolat készül, és a 
renciaszámlálás!!2 lehetővé teszi, ho: 
azokat az arculatokat. A már ismert 


locale osztályban alk: 
jj Á almazott refe. 
gy több objektum használhassa ügyése 








eclass Facets 





függvény megkeresi a megadott arculatot a n 
sablonparaméter alapján elvégzi a típuskon 
szeretnénk kérdezni, része-e egy adott arculai 


yelvi környezet listájában, és a 
verziót a leszármazottra. Ha le 
t a nyelvi környezetnek akkor a 


.. template cclass Facets 


. boo1l has facet(const localeg); 





sablonfüggvényt használjuk. Ezt a függvényt a fenti példánkban nem alkal. 
maztuk, a moneypunct arculat ugyanis szabványos, kötelez. 
nyelvi környezetnek. 

Több szabványos arculat két formában is megjelenik, például a már hasz- 
nált moneypunct arculatnak létezik egy moneypunct byname verziója is. 
A byname végződésű változatok az alapváltozatból származnak, és hozzáad- 
nak az ősosztályhoz egy olyan konstruktort, amely lehetővé teszi, hogy az ar- 
culatot egy C stílusú sztringgel inicializáljuk. A nyelvi környezetekhez hason- 
lóan itt is megadhatjuk az ország kódját, melynek eredményeképpen az arcu- 
lat az adott ország beállításaival jön létre. A byname arculatoknak nincs saját 
azonosítójuk, az alapverzió azonosítóját öröklik. A byname arculatok dest- 
ruktora protected, így nem hozhatunk létre belőle lokális változót. Ezért hasz- 
náljuk őket egy nyelvikörnyezet-objektumon keresztül, mert a nyelvi környe- 
zet a friend kapcsolat miatt el tudja érni a protected tagokat is, így fel tudja 
szabadítani az arculatobjektumokat. 

Példaként állítsuk be az alábbi környezetet: az operációs rendszer által 
meghatározott környezetet használjunk, de a pénznem beállításai a német 
konvenciókat kövessék. 


ő része a beállított 









locale loc(""); ge 
ocale: : global (Jocale(1oc, ú ún 
38 new moneypunct.byname cchar,truez ("German 


IG AZTSREMYK 





"2 A referenciaszámlálás a következőt jelenti. Minden arculatnak van egy belső számlálója. 
Mivel egy arculaton több locale típusú objektumpéldány is osztozik, nem lenne st 
csés, hogy az elsőként felszabadított nyelvi környezet felszabadítaná a destruktori ban íj; 
többiek által is használt arculatot. Ezért az arculat számlálóját nulláról Mlásörészele 
lahányszor egy locale típusú objektumhoz rendeljük, eggyel megnöveljük, (leh-é Belát 
locale objektum a destruktorában eggyel csökkenti a hozzárendelt arculato gs ralvó 
És csak akkor szabadítja fel, ha az nullává válik. Így biztosítható, hogy csa 
locale objektum szabadítsa fel a közös arculatot. 
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A fenti példában a loc változó konstruktorát ü res sztringgel inicializáltuk, ami 
r alapértelmezett beállításait jelenti. Ezek után létrehozunk 
egy új nyelvi környezetet : c al amely egy nyelvi környezet ég 
egy arculat összekombinálásával állítja elő az új nyelvi környezetet, Az újonnan 
létrehozott arculat felszabadításáról a nyelvi környezet gondoskodik. 13 

Nézzük meg, hogyan módosíthatjuk a már létező, szabványos arculatok 


az operációs rendsze! 









viselkedését! 





Feladat: Készítsünk olyan arculatot, amely a szabványos Ft rövidítés helyett kiírja a forint nevet! 





Megoldás 

A pénznemek szöveges értékeit a moneypunct arculat do curr symbol() virtuá. 
lis függvénye adja vissza. Vagyis le kell származtatnunk a moneypunct by. 
name osztályból, és azt kell hozzáadnunk a nyelvi környezethez. Ezt az alábbi 
kódrészlet mutatja be: 


templatecxclass charT, bool international - falsez 
class forint facet: public moneypunct. bynameccharT, international: 


t 
public: 
typedef basic stringccharT: string. type; 


explicit forint facet (const charT" name, 
const charT" forint value, size t refs-0) 
: moneypunct. bynameccharT, international: (name, refs), 
forint. value(forint. value) () 


protected: 
FÜL string. type do. curr. symbol() const 


return forint. value; 


private: 
5 String. type forint, value; 





§ Mivel az arculatokról is sekély másolat készül, a már említett módon egy belső referen- 
ciaszámláló számolja, hogy az arculat hány locale típusú objektumhoz tartozik. Ha egy 
locale felszabadul, ez a számláló eggyel csökken. Ha eléri a nullát, az utolsó locale típusú 
objektum felszabadítja az arculatot. Amennyiben ezt a viselkedést meg szeretnénk vál- 
toztatni, az arculat konstruktorának utolsó paraméterében megadott síze t paramétert 
kell nullánál nagyobb értékre állítani, amelyet az átad a facet ősosztálynak. Ennek az ér- 
téknek a szabvány szerint 1-nek kell lennie, Mivel ez az arculat belső referenciaszámláló: 
ját inicializálja, az sosem lesz nulla, így a nyelvi környezet sohasem szabadítja fel. Ezt a 
működést azonban nagyon ritkán szeretnénk előidézni. 
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12.6. nyelvű fejlesztés 
Az osztályt az alábbi kódrészlethez hasonlóan használhatjuk: 


TETTÉL ken tört AKÁKE KASÁKET EKKEGEOTTA 


talában is elmondhatjuk, hogy a szabványos ; 

El étidjük hogy leszármaztatunk a megát kese úgy 
tályból, felülírjuk a megfelelő virtuális függvényt, végül EL DS KSt LE 
környezethez. Itt jegyezzük meg, hogy ha az adott környezet SEÁATOS b vi 
magyar nyelvi környezetet, a fenti technikával létrehozhatjuk azt: jeztle 
szükséges arculat virtuális függvénye a magyar nyelvű sztringgel te Lk. 
Ha csak magyar nyelvi környezetet szeretnénk használni, akkor elég éke 
széles karaktert támogató arculatokat megírni, hiszen magyar program ese- 
tén széles karaktereket használunk. 

A nyelvi környezet kiegészítésének lehetőségét az alábbi feladaton ke- 
resztül mutatjuk be. 


E — — —  — — ee ele d 
Feladat: Készítsünk olyan arculatot, amely tárolja az adott országban használatos sebesség- 


konvenciót. Példaként készítsük el a magyar (km/h) és amerikai (mph) testre szabott arculato- 


kat! A felhasználást mutassuk be az előbbi pénzkonvertáláshoz hasonló függvényen keresztül! 
Mást e———————mygg ee sdd e detztendtenádtttttttte tesz áétetló áztláttártátetsttázttt 


Megoldás 


A feladat megoldásához saját arculatot kell készítenünk. Ennek az osztály- 
nak illeszkednie kell a nyelvi környezethez. Ez az illeszkedés az alábbi meg- 
kötéseket jelenti: 


9 Az osztályunknak a locale::facet osztályból kell származnia. 


s Az osztálynak tartalmaznia kell továbbá egy publikus locale:rid típusú, 
id nevű statikus változót. Ezt a locale konstruktora fogja használni az 
arculat hozzáadásakor, amelyet az arculatosztály típusával paraméte- 
rezünk. Ha nem adjuk meg, fordítási hibát kapunk, mert a locale osz- 
tálynak az arculattal paraméterezett konstruktora nem fordul le. 


A sebesség mértékegységét visszaadó ősosztályra az alábbi kódrészlet mutat 
egy lehetséges megoldást. 
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A konstruktort a származtatott arculatoknál már tárgyalt módon írtuk meg. 
A publikus velocity symbol függvény adja vissza a mértékegységet. Fontos, 
hogy a függvény konstans legyen, ugyanis a use facet sablon segítségével az 
arculatra csak konstans referenciát szerezhetünk az aktuális nyelvi környe- 
zettől. A velocity symbol egy tisztán virtuális függvényt hív, amelyet a le- 
származottakban felülírunk az adott ország mértékegység-rendszerének függ- 
vényében. A magyar konvencióknak megfelelő leszármazottat mutat be az 
alábbi kódrészlet: 


TEESNETET 





Az amerikai mértékegységrendszer szerinti , mérföld per órát" adja vissza az 
alábbi osztály: 









eme EEEN TEGGYGEYENVÜ FÜLEK 





Hangsúlyozzuk, hogy mivel nem szabványos arculatról van szó, meg kell vizs- 
gálnunk, tartalmazza-e a nyelvi környezet a velocity arculatot. Ezt a has facet 
sablon segítségével tudjuk megtenni. Ezek után a már ismert módon szer- 
zünk egy konstans referenciát a nyelvi környezet által tartalmazott velocity 
típusú arculatra, majd annak tagfüggvényét használva lekérdezzük a beállí- 
tásokat, és annak alapján konvertálunk. Feltételezzük, hogy a program belső 
adatreprezentációjának mértékegysége a km/h, ezért az átadott value para- 
méter is ebben a mértékegységben értendő. 
Az eddigieket az alábbi módon tesztelhetjük: 


Ez IT ez ze 
Útmutató: Csak akkor használjunk saját arculatokat, ha azok valóban az országokra jellemző 
kulturális vagy nyelvi beállítást valósítanak meg. Amennyiben a beállítás nem ilyen, EÁ 
használjunk mindenhonnan elérhető adatot lehetővé tévő megoldásokat (jellemzően statikus 


Magyar nyelvű szövegfeldolgozás 
A nemzeti sajátosságok leginkább a szövegfeldolgozás jellegű műveletek terén 
mutatkoznak meg, ezért a nyelvi környezetek e vonatkozásait mi 15 


San tárgyaljuk. A szövegfeldolgozási műveletekhez kapcsolódó kulturális beállí- 


tásokat a ctype és a collate szabványos arculatok tartalmazzák. Ugyanakkor 
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éppen ezeknek a műveleteknek a fontossága miatt nem kell ezekhez az arcula. 
tokhoz közvetlenül hozzáférnünk: globális függvények és operátorok teszik ké. 
nyelmesebbé a kultúrafüggő szövegkezelést. Elsőként bemutatjuk az egyszerű. 
sítéseket, majd rátérünk az említett arculatok funkcióinak tárgyalására. 

A locale objektum túlterhelt zárójel operátora olyan sablonfüggvény, amely 
két széles vagy szűk karakterből álló sztringet hasonlít össze. Az összehasonlí. 
tásnál megszokott módon az operátor igazzal tér vissza, ha az első sztring van 
előbb az ábécében, ellenkező esetben hamissal (egyenlőség esetén is). 





A programrészlet kimenete az alábbi: 


(A sorrend: 2 I: Adoi 





Kiemeljük, hogy a locale zárójel operátora nem C sztringeket, hanem Ct- stí- 
lusú basic string típusokat hasonlít össze. 

Felmerülhet a kérdés, hogy miért pont a zárójel operátor túlterheléseként 
érhető el ez a funkcionalitás. Ha felidézzük a függvényobjektumokról alkotott 
ismereteinket (12.1.3. Algoritmusok fejezet Műveletek mint algoritmusargu- 
mentumok rész), akkor észrevehetjük, hogy így a locale típusú objektumok 
függvényobjektumként is használhatók. Ezt mutatja be az alábbi példa: 











A programrészlet kimenete pedig az ábécérendbe állított névsor: 





Az egyes karakterekkel kapcsolatos kultúrafüggő függvényeket elérhetjük az 
std névtér globális sablonjaiként. A sablonparaméter a karakter típusa, 
amely lehet szűk (char) vagy széles (wchar t). Ezek a függvények csak akkor 
térnek vissza igazzal, hogyha a hozzájuk tartozó feltétel teljesül, amelyeket a 
következő táblázat foglal össze. 





bool isspace (charT c, const localedt loc) szóköz jellegű karakter 


bool isprint (charT c, const locale loc) nyomtatható karakter 
bool iscntrl (charT c, const locale loc) vezérlő karakter 

bool isupper (charT c, const localedt loc) nagybetű 

bool islower (charT c, const localeg loc) kisbetű 

bool isalpha (charT c, const locale loc) betű 

bool isdigit (charT c, const localedt loc) számjegy 

bool ispunct (charT c, const localedt loc) írásjel 


bool iszdigit(charT c, const localedt loc) hexadecimális számjegy 

bool isalnum (charT c, const localedt loc) betű vagy számjegy 

bool isgraph (charT c, const localedt loc) betű, szám, vagy írásjel 

9. táblázat 

Ezeken kívül van még két konverziós függvény, amelyek az adott nyelvi kör- 


Nyezetre jellemző karakterkészlet alapján elvégzik a kis- és nagybetűre tör- 
konyverziót, 
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m——ű———u— u usse EE 














Függvény Leírás 
charT toupperícharT c, const locale loc) nagybetűvé konvertál 
charT tolower(charT c, const localedt loc) kisbetűvé konvertál 


mel 
10. táblázat 


A fenti függvényeket nagyon hasonlóan kell felparamétereznünk, használa. 
tukat egy rövid példán illusztráljuk: 


wchar.t wc z LIÁ!; 


1ocale locHu("hungarian") ; 
cout cc isalpha(wc, 1ocHud; // 1 
wcout cc tolower(wc, locHu); // á 


Az isspace függvény segítségével egyszerűen készíthetünk olyan függvényt, 
amely levágja a szóköz jellegű karaktereket a ring elejéről, illetve a végé- 
ről. Mivel ezekre a műveletekre gyakran van szükség szövegfeldolgozási fel- 
adatok esetén, bemutatunk egy lehetséges megvaló 









templatecclass charTz 
void trim left(basic stringccharT2€ str, 
const localeg loc slocale()) 


for(basic stringccharT2::iterator it - str.beginO; 
it !z str.endO); $rrit) 


if(!isspace(rit, 10c)) 
1 


str.erase(str.beginO , it); 
return; 
ő J 
// Ha végig szóköz jellegű karakter volt 
str.clearO; 
3 


A függvénynél ismét ügyeltünk arra, hogy mind közönséges, mind széles ka- 
rakterekre működjön, valamint, ha a függvény felhasználója nem szeretne 
foglalkozni a nyelvi környezetekkel (mivel megfelel neki a globális beállítás), 
akkor erre ne is legyen szükség. Az első célt úgy értük el, hogy sablonparamé- 
terként adtuk meg a használandó karaktertípust, a második esetében a locale 
típusú paramétert az alapértelmezett konstruktor által visszaadott nyelvi 
környezettel inicializáltuk, amely az aktuálisan beállított globális nyelvi kör- 
nyezetet adja vissza. A függvényben a sztring iterátorinterfészét használtuk a 
sztring karakterenkénti bejárására, valamint az isspace globális függvényt 
annak eldöntésére, hogy egy karakter szóköz jellegű-e. 
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A trim right függvényt fordítóiterátorok segítségével a trim left függ- 
vényhez nagyon hasonlóan implementálhatjuk. v 


templatecclass charTs ree 
void trim right(basic stringccharTsg str, 
const localeg locslocale()) 


fi i j j 
forCbasic. stringecharT5: :reverse.iterator rit - str.rbeginO; 
rit !- str.rendO; ssrit) 


1 
if(!isspaceCstrit, 10c)) 


fd t 4 
// A fordítóiterátort iterátorrá alakítjuk 
// a base tagfüggvény segítségével (eltolást is jelent) 
str.erase(rit.baseO) , str.end()); 
return; 


h 


h 
// Ha végig szóköz jellegű karakter volt 
str.clearO; 


1 


A fordítóiterátor base() tagfüggvényének segítségével kaphatunk egy iterátort a 
fordítóiterátor álta! mutatott pozícióra (12.1.2. Iterátorok fejezet Iterátoradap- 
terek rész). Erre a példánkban azért van szükség, mert a sztring erase tagfügg- 
vénye nem fordítóitorátort vár. Természetesen ezúttal a sztring végéről kell el- 
távolítani a szóköz jellegű karaktereket. A függvények használata egyszerű: 


wstring trim zs L" Ntálmos Mt"; 
trim left(trim); 
trim right(trim); 
wcout cc trim cc L"I"; //Álmosl 


Ha nem a globális nyelvi környezetet akarjuk használni a szóköz jellegű ka- 
rakterek eltávolítására, természetesen azt is megadhatjuk a függvények utol- 
só paramétereként. 

A kultúrafüggő rendezést a collate arculat támogatja. Ennek egyetlen sab- 
lonparamétere a használt karaktertípus. Az arculatnak három fő funkciója van: 


s — két sztring összehasonlítása, 

s — hasítóérték számítása, 

§ a gyors összehasonlítást támogató rendezőkulcs generálása. 
Ezek a függvények bemeneti paraméterként nem C-t stílusú sztringet vár- 
nak, hanem karakterekből álló tömböt. Ezeket a tömböket az első karakterre 


és az utolsó karakter után mutató pointerrel adhatjuk meg. Ez a megoldás a 
sztring végét nem a N0" karakterrel adja meg, hanem egy mutatóval, tehát a 
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lezáró "90" nem szükséges. Ez a paramétermegadási mód hasonlít az iterátor. 
tartományokra, ugyanúgy nyílt az intervallum: a tartomány végét jelző poin.- 
z utolsó elem után mutat 

Isőként tekintsük át az 
culat compare tagfüggvényével vé: 











szehasonlítás műveletét, amelyet a collate ar. 
gezhetünk! 


wstring wstr1 s L"Előd"; 
wstring wstr2 - L"Álmos"; 


typedef collatexwchar. t: collate. type; 
const collate typeg cl z- use facetccollate, typex(Iocale()); 


int order - cl.compare(wstr1l.data(), wstr1.data()-wstr1.size() , 
wstr2.data() , wstr2.dataO twstr2.size()); 

if( order -— -1) 

s § 


wcout cc L"A sorrend: " cc wstr1l cc! "cs wstr2; 


else if(order -— 1) 


ki 
wcout cc L"A sorrend: " ac wstr2 cc" "cc wstrl; 
3 
else 
1 
wcout cc L"A két sztring egyenlő" cc endi; 
l 


7/ A sorrend: Álmos Előd 


A compare tagfüggvény -1-gyel tér vissza, ha az első sztring van előrébb az 
ábécében, 1-gyel, ha a második, és nullával, ha megegyeznek. Itt jegyezzük 
meg, hogy a locale zárójel operátora is a collate arculat compare tagfüggvé- 
nyét használja, és a legtöbbször az alábbi módon implementálják: 


return use. facetccollatecxcharTs 3("this) compare (s1.data(), 
s1.dataOss1.sizel) , s2.dataO) , s2.dataO)4s2.size()) c 0; 


Egy sztringre hasítóértéket is számolhatunk: a művelet eredménye egy olyan, 
long típusú m, amely két sztringre számolva nagy valószínűséggel csak 
akkor egyenlő, ha a két sztring is azonos volt. Ha két különböző sztringre 
a hasítóérték, akkor ütközésről beszélünk. A szabvány előírja, hogy 
itközés valószínűségének a maximális long típusú érték reciprokát kell kö- 
zelítenie. A hasítóértéket a collate arculat hash tagfüggvényével számíthatjuk. 














typedef collatexwchar. ts collate type; 
const collate typeg cl - use, facetccollate types(Iocale(); 


wstring wstr1  L"Előd"; 
wstring ws L"Álmos" ; Höcai é g 
Wwstring WStrZ(wstr2dp 3 
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cout cc c1l.hash(wstr1. " WStrl.dataÓ 4 . $ 
leég él hashitáeréslsttt, wstr2.dataÓ 4 ir loeet seta] pity: ak 
cout cc c1.hash(wstr3.dataÓ , wstr3.dataÓ 4 wstr3.síze0) ec endi, 





A programrészlet például az alábbi kimenetet eredményezi: 


1164792164 
1819111476 
1819111476 


Az eredmény természetesen függ az adott implementáció által használt hasító- 
algoritmustól, ugyanakkor implementációtól függetlenül elmondható, hogy a 
két utolsó eredmény megegyezik, és az első hasítóérték nagy valószínűséggel 
eltér a másik kettőtől. 

A collate arculat harmadik szolgáltatásának megértéséhez idézzük fel, hogy 
a magyar nyelvre már nem igaz, hogy karakterenként zehasonlítva az egyes 
kódpontok értékeit a magyar nyelv szabályainak megfelelő ábécé 
dezéshez jutunk. Így közvetlenül nem használhatjuk ezt a gyors összehasonlí- 
tási mechanizmust. Ha viszont egy sztringet számos másik sztringgel akarunk 
összehasonlítani, még az is megéri, hogy a sztringekből képezünk olyan sztringe- 
ket, amelyekre a karakterenkénti összehasonlítás ugyanazt az eredmény adja, 
mint a kultúrafüggő összehasonlítás az eredeti sztringekre. Ezt a műveletet 
rendezőkulcs-generálásnak (sort key generation) nevezik. Ezt végzik a szab- 
ványos sirxfrm és wcsxfrm C függvények. Ezek megfelelőjét a C--4-ban a 
collate arculat transform tagfüggvénye adja. Ennek használatát az alábbi 
példa illusztrálja, amelyben feltételezzük, hogy az előző példa deklarációi 
rendelkezésre állnak. 








rinti ren- 


















// Először transzformáljuk az eredeti sztringeket 

wstring twstr1 - c1l.transform(wstr1.dataO , 
wstr1.data()wstr1.size0) ; 

wstring twstr2 - cl.transform(wstr2.data() , 
wstr2.dataO wstr2.sizeO) ) ; 


// A karakterek értéke szerinti, karakterenkénti 

// összehasonlítás a rendezőkulcsokon k 

bool is. first less - lexicographical compare(twstr1.beginO , 
twstr1.endO , twstr2.begin(), twstr2.end(); 


// Ugyanaz az eredmény, mintha az eredeti sztringeket hasonlítottuk 
// volna össze 
KE s.fírst. less) 


Wwcout cz LVA sorrend: " ax wstrl ec! "as wstr2; 
else 


( 


Wcout cc L"A sorrend: " ac wstr2 cc! "cg wstrl; 
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Megjegyezzük, hogy az ábécé szerinti összehasonlítás bonyolultsága miatt a ke. 
letkező sztring magyar nyelvi környezet esetén hosszabb, mint az eredeti, 114 

A collate arculatra is igaz, hogy az egyes tagfüggvények működése virtuális 
tagfüggvények felülírásával a Nyelvi környezetek C44-ban részben bemutatott 
módon megváltoztatható, ezek a do compare, a do hash és a do. transform 
függvények. 

Az ASCII kódtábla kiterjesztése azt eredményezte, hogy bizonyos karak- 
terosztályok például a magyar és számos más nyelv esetén nem összefüggően 
a-tól z-ig lettek kódolva. Így az osztályozás is bonyolultabbá vált, mint az angol 
nyelvnél. A karakterosztályozás nyelvi környezettől függő kezelését a ctype 
arculat végzi. A etype arculatnak három fő szolgáltatáscsoportja van: 


e — karakterosztályozás, adott típusú karakter keresése karaktertömbben, 
s — kis- és nagybetűk közötti konverzió, valamint 
s — széles és közönséges karakterek közötti egyszerű konverzió. 
A ctype arculat tagfüggvényei az egyes karakterosztályokat jelzőbitekkel jelö- 
lik. Ezek a jelzőbitek a ctype ősosztályán, a ctype base osztályon belül a mask 


nevű enum-ban vannak definiálva. Az egyes jelzőbiíteket és azok jelentését a 
következő táblázat foglalja össze. 





space szóköz jellegű karakter 





























print nyomtatható karakter 

entrl Vezérlőkarakter 

upper Nagybetű 

lower kisbetű 

digit számjegy tízes számrendszerben 
punct írásjel 

xdigit hexadecimális számjegy 

alpha betű 

alnum alpha [digit — számjegy vagy betű 
graph alnum Ipunct — számjegy, betű, vagy írásjel 
11. táblázat 





"4 A rendezőkulcs generálásának számos platformfüggő megoldása van. Windows alatt az 
L7á" sztring transzformáltja nem nyomtatható karakterekből áll, melyeknek értékei: 
142114 1 1 1 0. A probléma jó áttekintését adja, és szabványos megoldást nyújt rá a 
Unicode Collation Algorithm (UCA) (http:/www.unicode.org/reports/tr10/. 
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12.6. Magyar nyelvű fejlesztés 
Az alábbi függvény megállapítja, hogy egy adott közönséges karakter számjegy-e. 





1 isdigit(char c, locale 1060) 





return use. facetcctypecchars 5(10c) .is(ctype. base: :digit, 0): 
A ctype arculat is sablonosztály, sablonparamétere a használni kívánt karak- 
tertípus. Az is tagfüggvény egyik túlterhelése eldönti, hogy egy karakter a 
megadott karakterosztályba tartozik-e. Paraméterei a kategorizálandó karak- 
ter, illetve a fenti táblázat jelzőbitjei, esetleg logikai operátorokkal összekap- 
csolva. A fejezet elején tárgyalt kényelmi sablonfüggvények implementációja 
nagyon hasonlít a fenti példára, a lényegi különbség annyi, hogy a globális 
függvényeket a karaktertípussal parametrizálták. 





Útmutató: A rövidebb és áttekinthetőbb kód végett a ctype arculat tagfüggvényei helyett [ ; ] 
használjuk az azoknak megfelelő globális függvényeket! 


A ctype arculat is tagfüggvényének van egy másik túlterhelése is, amely a 
collate arculatnál tárgyalt módon két pointerrel megadott sztringet vár, illet- 
ve egy maszkvektort. A tagfüggvény a maszkvektorban jelzőbitek kombiná- 
ciójával visszaadja az egyes karakterek jellemzőit. A scan is tagfüggvény egy 
jelzőbitkombinációt és egy sztringet vár két pointerrel megadva, és visszatér 
az első olyan karakterre mutató pointerrel, amely kielégíti a jelzőbitkombiná- 
ciót. A scan not nagyon hasonlít a scan is tagfüggvényre, a különbség csak 
annyi, hogy ez utóbbi az első olyan karaktert keresi meg, amely nem felel 
meg a paraméterként megadott jelzőbitkombinációnak. 

A nagybetű/kisbetű átalakításokat a toupper és tolower tagfüggvények 
végzik. A karaktereket átalakító függvények globális függvényként is megje- 
lennek. A karaktertömbök átváltását végző tagfüggvények viszont csak a 
ctype arculaton keresztül érhetők el. Ezek használatára mutat egy példát az 
alábbi kódrészlet: 


wchar.t wtext1(] - k 
a L"árvíztűrő tükörfúrógép ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP" ; 


ő wchar.t wtext2[(] - 5 
L"árvíztűrő tükörfúrógép ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP" ; 


E a 
. use facetcctypexwchar. ts 3(10c) . toupper (wtext1 3 
ik 48 jéé BÉL] wtextl r wcslen(wtext1)); 


" use facetect har-ts 5(10c) . tolower (wtext2 , 
TET SEAT EkÁGzáSatáÁa AN zánEá ANG wtext2 4 wcslen(wtext2)); 





.  WCOut cc wtextl cs endi; -9n 
. // árvíztűrő tükörfúrógép árvíztűrő tükörfúrógép 


[1 OZ $; 
"  WCOUt cc wtext2 cc endi; 


ú EZSKOSÁTHABI TÜKÖRFÚRÓGÉP ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP 
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12. fejezet: Bevezetés a Cs szabványos sablonkönyvtárába 





Amennyiben sztringekre ís meg szeretnénk írni ezt az igen hasznos függ. 
vényt, több megoldás közül választhatunk. Kihasználhatjuk, hogy a sztring 
típusok íterátora a legtöbb platformon közönséges pointer, így átadhatjuk a 
begin() és az end() tagfüggvények eredményét a ctype arculat karaktertömböt 
váró tolower és toupper függvényeinek. Mivel ez nem előírás, nem jelent hor. 
dozható kódot. Második megoldásként lekérdezhetnénk a sztring adatterüle. 
tét karaktertömbként. Most azonban meg kell változtatnunk ezt a területet 
és megváltoztatható formában k a másoláson keresztül kérdezhetjük ég 
sztringek copy tagfüggvényével. Ezzel a módszerrel túl sok lenne a másolás, 
Ezért az iterátorintefészen keresztül karakterenként konvertáljuk a sztringet, 














templatecclass charT: 
void tolower(basíc stríingccharToé str, 
const localeg loc - locale()) 
t 
typedef basic stringccharT: string. type; 


for(string type::iíterator ít - str.begínO; 
ít !z str.endO ; 4riít) 
( 


trit z tolower(rit, 100); 


, 
J 


templatecclass charT: 

void toupper(basic stringccharTo$ str, 
const localeg loc z locale()) 

( 


typedef basic stringccharT; string type; 


forCstring type::iterator it - str.beginO; 
ít !- str.end(); rrit) 
( 


tít z toupper(rit, 10c); 


J 


A etype narrow és widen tagfüggvényeinek túlterhelései a széles és közönsé- 








ges karakterek, illetve karaktertömbök közötti legegyszerűbb konverziót va- 
lósítják meg implementációtól függő módon. Általánosságban elmondható, 


hogy ez a művelet a legtöbb fordító esetén ASCII karakterekre a várakozás- 
nak megfelelően működik. Ha a ctype sablonparamétere charT, akkor a widen 
char típusról konvertál charT típusra, a narrow pedig wchar t típusról char 
típusra. Vagyis a példányosítástól függően az egyik függvény semmit sem 
csinál. Különösen jól jön ez a tulajdonság, amikor közönséges karakterekből 
álló sztringkonstansokat szeretnénk használni olyan sablonokban, ahol a ka- 
raktertípus a sablonparaméter. 


414 





12.6. Magyar nyelvű fejlesztés 





A probléma az, hogy a széles karaktereket nem lehet a közönséges karak- 
tereket tartalmazó sztringhez hasonlóan inicializálni, az idézőjel elé ugyanis 
kell az L karakter. mivel nincs automatikus konverzió a közönséges és a ső 
les karakterekből álló C stílusú sztringek között. e 


wcharat kmh(] — "km/h"; // Hibás 
wchar-t kmh(] - L"km/h"; // Helyes 


Az alábbi függvény úgy működik mind string, mind wstring paraméterekre: 
mindkét esetben a "km/h" konstanssal inicializálja a sztringet. 


templatecclass charTs5 
void init(basic stringccharT5€ str, const localeg loc - locale()) 


ő char speed(]-"km/h"; 
charT result(sizeof(speed)]; 
use. facetcctypeccharTs 3(10c) .widenCspeed, speed 4 
sizeof(speed)/sizeof(speed(0]), result); 
str - result; 


) 


Az egyetlen karaktert átalakító függvényeket az adatfolyamok azonos nevű 
tagfüggvényei is használják, könnyebb hozzáférést biztosítva a ctype ezen két 
tagfüggvényéhez. 

Rövid sztringek és csak ASCII karaktereket tartalmazó konstansok ese- 
tén az a megoldás is célravezető lehet, hogy a tömbszintaxist használjuk az 
inicializáláshoz, ahol karakterenként már létezik automatikus konverzió: 





charT speedf(] c ("kt,tmi zt hto); 
A függvény ebben az esetben az alábbi módon valósítható meg: 


templatecclass charT: 
void init(basic stringecharTs€ str, const localeg loc - 1ocale()) 


charrT speed(]J-ítkt,tmt, "zt, thi; 
Str - speed; 


Az eddig megszokott konvenciókhoz hasonlóan a etype arculat publikus függ- 
vényei protected virtuális függvényekkel lettek megvalósítva, így biztosítva a 
kiterjeszthetőséget. Ezek a függvények továbbra is do. előtaggal kezdődnek. 


Kódolások közötti konverziók 


Amint azt a bevezetőben is említettük, egy Ctt program be zel 
Zentációja más lehet, mint a külső, amelyet például állományba írást 
nál, Ezekhez a konverziókhoz a codecut arculaton keresztül férhetün 


Iső karakterrepre- 
nál hasz- 
k hozzá. 
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12. fejezet: Bevezetés a Css szabványos sablonkönyvtárába 


Az arculatnak három sablonparamétere van: az első a program által használt 
belső karaktertípus, a másik a külső karaktertípus, a harmadik a konverzió 
állapotinformációját tároló objektum típusa. A szabvány két példányosítást ír 
elő kötelező jelleggel: 


e — codecvtcchar, char, mbstate t2 


e — codecutáwchar t, char, mbstate t2 


Az első egy elfajult konverzió, nem csinál semmit, a másik a széles és a kö. 
zönséges karakterek közti konverziót valósítja meg. 

A következő példa az aktuális nyelvi környezet alapján átkonvertál egy 
széles karaktereket tartalmazó sztringet szűk karaktereket tartalmazó 
sztringre a megfelelő nyelvi beállítás alapján. 


typedef codecvtewchar.t, char, mbstate t: codecvt type; 
const codecvt. typeg cvt - use facetccodecvt. type:(10c) ; 


mbstate t state - 0; 
wstring wtest - L"árvíztűrő tükörfúrógép ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP" ; 
vectorcchar: v(íwtest.sizeO "cvt.max lengthO); 


const wchar. tt wfirst, unconverted src; 
char? first unconverted dst-év[0]; 


codecvt. type: :result result - 
cvt.out(state, wtest.data(), wtest.data()-wtest.size() , 
wfirst. unconverted src, €v[0], €vf0]Jtv.sizeO, 09 
first unconverted dst) 








v.resize(first unconverted dst-év[0]); 


if(result !- codecvt. type: :ok) 
throw runtime, error("Hiba"); és ee] 


A vektornak az arculat max length függvénye segítségével foglalunk dinami- 
kus memóriát: ez a függvény megmondja, hogy egy bemenő karakterhez leg- 
rosszabb esetben hány kimeneti bájt tartozik. Az out függvény a konverzió ál- 
lapotát tároló változón kívül a konvertálandó karaktereket várja nyílt inter- 
vallum formájában, majd egy pointerreferenciát vár, amelyen keresztül visz- 
szaadhatja, hogy a konvertálandó karaktersorozatban meddig jutott el a kon- 
vertálás során. A pointer az első már nem konvertált karakterre mutat. Ha- 
sonló módon adhatjuk meg a céltartományt, amelyben az utolsó paraméter 
jelzi, hogy meddig jutott a konverzió. Ha a függvény nem tért vissza hibával, 
ez utóbbi pointert használjuk arra, hogy beállítsuk a vektor méretét az érvé- 
nyes adattartományra, a helyfoglaláskor ugyanis a legrosszabb esetet vettük. 

A visszafelé irányban végrehajtott konverzió nagyon hasonló. Itt a codecut 
arculat in tagfüggvényét használjuk: 
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Ha lefuttatjuk az alábbi programrészletet, és mindegyik kódrészlet ugyanazt 
a nyelvi környezetet használta, akkor az állomány tartalmának meg kell 
egyeznie a fenti kódrészletek v vektorának tartalmával. 





Ennek az a magyarázata, hogy az adatfolyamok és az adatfolyambufferek is a 
hozzájuk rendelt nyelvi környezetből veszik a codecut arculatot, és a fent be- 
mutatott konverziót használják az adatfolyambufferek is, vagyis az állo- 
mánybeli formátumot kapjuk meg az eredményt tartalmazó bájttömbben.!15 
Hangsúlyozzuk, hogy az esetek túlnyomó többségében az adatfolyambuffereken 
keresztül használjuk a codecut szolgáltatásait. 

Számos könyvtár létezik, amely a codecut arculaton keresztül biztosítja a 
konverziót UTF-8 és más formátumokba. Ilyenkor szokás szerint létre kell 
hozni az általuk megadott, codecvt-ből származó arculatból egy példányt, hoz- 
zá kell adni egy nyelvi környezethez, és a nyelvi környezetet hozzá kell ren- 
delnünk az adatfolyamhoz. Ennek módjáról részletesen a következő részben 
lesz szó. Amennyiben saját codecvt alapú konvertert szeretnénk létrehozni, 
továbbra is a do. előtaggal kezdődő virtuális függvények felülírását kell érte- 
lemszerűen elvégezni. Erre példát a [3] irodalomban találhatunk. 


A nyelvi környezetek és az adatfolyamok kapcsolata 


A nyelvi környezetek leggyakoribb alkalmazási területét az adatfolyamok je- 
lentik. Vegyük az alábbi példát! 


ze etés SEN K 
" Rz Windows alatt a beállított nyelvi környezet által meghatározott kódlap szerinti ka 
rakterekre konvertálja a Unicode kódpontokat. 
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12. fejezet: Bevezetés a Crr szabványos sablonkönyvtárába 


Jól látható, hogy alapértelmezésben a lebegőpontos számok kiírásánál a cout 
tizedespontot használ. Ha azt szeretnénk, hogy a magyar szokás szerint tize- 
desvesszőt írjon ki tizedespont helyett, akkor hozzá kell rendelnünk a magyar 
nyelvi környezetet a cout adatfolyam-objektumhoz. Ezt az imbue tagfügg. 
vénnyel tudjuk megtenni: 


Vagyis a C-vel ellentétben a Ct--ban lehetőségünk van rá, hogy egy adatfo- 
lyamhoz nyelvi környezetet rendeljünk. Alapértelmezésben az adatfolyamok 
a létrejöttükkor aktuális globális nyelvi környezetet használják. Mivel a cout 
programinduláskor jön létre, amikor a beállítás a klasszikus C nyelvi környe- 
zet, ezért mindig ez az alapértelmezett. Ez lehetővé teszi, hogyha nem szeret- 
nénk speciális nyelvi beállításokat, akkor minden adatfolyam automatikusan 
a globális nyelvi környezet beállításait használja. Mivel az adatfolyam a létre- 
jöttekor a locale() konstruktorral másolatot készít az aktuális globális nyelvi 
környezetről, a globális nyelvi környezet további változásai nem érintik a már 
létrejött adatfolyamot. Az adatfolyam létrejötte után csak az imbue tagfügg- 
vénnyel változtathatjuk az adatfolyamhoz rendelt nyelvi környezetet. 

Ha amerikai beállítás szerint szeretnénk beolvasni egy számot, és magyar 
szabályok szerint szeretnénk kiírni, erre egy hibakezelés nélküli megoldást 
mutat a következő kódrészlet: 





Itt látható az előnye annak, hogy a Ct--ban az egyes adatfolyamokhoz külön 
nyelvi környezetet rendelhetünk. C-ben ilyenkor a beolvasás és a kiírás kö- 
zött váltogatnunk kellene a globális nyelvi környezetet. Viszont láttuk, hogy 
C-4-ban éppen ez nem működik, mert a már létező adatfolyamokra nincs ha- 
tással a globális nyelvi környezet megváltoztatása. Ha azt szeretnénk, hogy 
az adatfolyam az új globális nyelvi környezetet használja, akkor ezt a 
std::cout.imbue(locale()) függvényhívással érhetjük el. 

Figyelnünk kell arra is, hogy mikor cseréljük ki az adatfolyamhoz rendelt 
nyelvi környezetet. Ha ugyanis az adatfolyambuffer éppen egy olyan konverziót 
végez, ahol figyelembe kell vennie a korábbi bájtokat is (például UTF-8-ról 
UNICODE kódpontra), akkor könnyen előfordulhat hibás adat. 


418 





TREZGTEKE ÉT ját ety ERNE ÁL ÁE KET — 
Útmutató: 
— Az adatfolyamhoz mindig hozzárendethetünk nyelvi körn 
bármilyen műveletet végeznénk rajta. 





Ji) 


yezetet biztonságosan, mielőtt 


— Minden olyan művelet után biztonságosan kicserélhetjük hús 
üríti (flush) az adatfolyambuffert. J9k a nyelvi környezetet, amely ki: 


S ÉS sétlézeeőélérszeei élo 164 


Az adatfolyamok a ctype, num put, és num get arcul. tn 
folyambufferek pedig csak a codecut árulatotáó Köze eni et ket 
bufferhez is rendelhetünk nyelvi környezetet: ilyenkor az adatfol. GLZEő 
pubimbue függvényét használjuk. yambuffer 
Az eddigiekben áttekintettük, miként rendelhetünk hozzá nyelvi körn. 
tet az adatfolyamokhoz, illetve az adatfolyambufferekhez. Láttuk. hogy az Sat 
folyamok és az adatfolyambufferek bizonyos szabványos azóllatokát ALGIn EE 
kusan használnak. A továbbiakban megvizsgáljuk, miként használhatjuk az 
adatfolyamokhoz rendelt többi, esetleg saját magunk készítette arculatokat. 


Feladat: Írjuk meg egy időt egységbe záró osztály beolvasó és kiíró operátorait! 


Megoldás 


Először létrehozunk egy leegyszerűsített Time osztályt. 






memset(gtime,0, sizeof(std::tm)); 
met now z std;::time(NULL); 





Az osztály a C nyelvben megszokott ím struktúrát használja az idő belső repre- 
Zentációjaként. Így könnyen kibővíthető olyan tagfüggvényekkel, amelyek a [e 
függvényeket használják és teszik biztonságossá. A továbbiakban a beolvasásra 
89 kiírásra koncentrálunk. Eddig ezeket ostream, illetve istream osztályokra 
írtuk meg. Most azonban a sablonok segítségével egyszerre készítjük el ezeket 
a funkciókat ostream és wostream, illetve istream és wistream adatfolyamosz- 





8 ú EYETTT 797 Fi a 
zi Hangsúlyozzuk, hogy az adatfolyamok nyelvi környezetének átállítása nem jelenti a kon- 
zol, illetve terminál átállítását. 
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tályokra. Mint ahogy a string és a wstring a basic string sablon példányosítása, 
az ostream és a wostream a basic. ostream példányosításai char, illetve wechar t 
típusra. Az istream és a wstream típus pedig a basic. istream példányosítása, 
Így a sablonparaméterekkel a basic ostream, illetve a basic istream osztályo. 
kat példányosítjuk. Ismét emlékeztetünk rá, hogy ezek a C nyelvben alkalma. 
zott makrót használó megoldás C-t--ban alkalmazott alternatívái. 

Nézzük először a kiírást! A kiíráshoz a time put arculatot használjuk, 
amelynek put tagfüggvénye egy ím típusú struktúrát ír ki az strftime C függ- 
vény formátumait felhasználva. A hatékonyság kedvéért a kiíráshoz nem az 
adatfolyamot használjuk, hanem közvetlenül az adatfolyambufferbe írunk, 
Egy lehetséges megoldás az alábbi: 








template cclass charT, class Traitsz 
std::basic ostreamccharT, Traitss€ operator cc 

(std::basic ostreamccharT, Traitso;€ os, const Time § t) 
tú 


std::basic ostreamccharT, Traitsz::sentry sntr(os); 
ifCisntr) return os; 


std;:use facetc 
std::time. putccharT, ostreambuf íteratorccharT,Traitsz 5 2. 
(os.getloc()) .put(os,os,os.fil1() ,€t.time, "x); 


os.width(0) ; MEZ 
return os; j 
bi MÉLSDTSÁRA 


Mivel alacsony szintű műveletet hajtunk végre, egy sentry típusú objektumot 
kell létrehoznunk [14]. Ez különböző inicializ; műveleteket végez, és több- 
zálú környezetben zárolja (lock) az adatfolyamot. A sentry destruktora elvég- 
zi a szükséges szinkronizációs és egyéb műveleteket. Fontos, hogyha sentry 
típusú objektumot használunk, akkor ne hívjuk az adatfolyam kimeneti vagy 
bemeneti műveleteit. Ezek a műveletek ugyanis szintén használnak sentry tí- 
pusú objektumot, és megpróbálhatják zárolni az adatfolyamot, amelyet a mi 
sentry típusú objektumunk foglal le, így kölcsönös várakozás alakul ki holt- 
pontot (deadlock) eredményezve. Helyettük az adatfolyambuffer műveleteit 
kell használnunk. A time put arculat függvényei egy kimeneti iterátort vár- 
nak, amelyre kiírhatják az időt szöveges formátumban. Ezért a time put pa- 
raméterei a kimeneti iterátor típusa, illetve az, hogy széles vagy szűk karak- 
tert használunk. A kimeneti iterátor típusa most egy kimenetiadatfolyam- 
buffer. A put függvény első paramétere éppen ilyen típusú. Az ostreambuf. 
iterator sablonnak van egy olyan konstruktora, amely egy adatfolyamot vár, 
lekérdezi az adatfolyam bufferét, és arra állítja rá magát. Ezért adhatjuk át 
az adatfolyamot első paraméterként. A második paramétert a szabvány nem 
részletezi, használata implementációfüggő, némely implementáció figyelmen 
kívül hagyja, mások további formázást olvasnak ki belőle. A harmadik para- 
méter a kitöltő karaktert adja meg, a negyedik a használt tm típusú struktú- 
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rára mutató pointer. Az utolsó paraméter az strftime C függvény formátumot 
meghatározó karakterei közül valamelyik. Mivel az a konvenció, hogy 
lességre vonatkozó beállítást minden kiíratás után végre kell h. 3 
térés előtt kezdőállapotba állítjuk. 

A beolvasás megvalósítása koncepcióiban nagyon hasonlít a kiírásra. Egy 
lehetséges megoldást a következő kódrészleten láthatunk. a s 


a szé 
ajtani, vissza- 





template cclass charT, class Traitss 
std::basic ístreamccharT, Traitss€ operator sz 

(std::basic istreamccharT, Traitssg is, Time gt) 
hd 


std::basic istreamccharT, Traitsz::sentry sntrCis); 
if(!Isntr) return is; 


std::ios base: :iostate state z 0; 
std::tm temp; 


std::use.facet c 
std::time.get acharT, std::istreambuf iterator 
c charT, Traitsz 5 
z 
Cis.getlocO) .get.tíme(is, 
std::istreambuf iteratorccharT,Traits2(), is, state, €temp); 


if(state 4 ios::failbít) 
1 


is.setstate(ios::failbit); 


else 
t 
t.timeztemp; 


is.width(0) ; 
return is; 
J 


Ezúttal a time get arculatot használhatjuk. A get. time függvény első paramé- 
tere a beolvasandó karakterek elejére állított iterátor, a másik a karakterso- 
rozat vége utáni elemre mutató iterátor. Az alapértelmezett konstruktorral 
létrehozott adatfolyam-iterátor az állomány vége pozíciót jelöli, ezért ezt ad- 
juk át második paraméterként. A harmadik paraméter a kiírásnál ismerte- 
tett, implementációfüggően értelmezett érték. A negyedik paraméterben b hi- 
bát kapjuk meg az adatfolyamok állapotánál megszokott módon. Végül a feltöl- 
tendő tm típusú struktúra címét adjuk át. A függ yhívás után ellenőrizzük a 
helyes működést. Ha minden jól ment, feltöltjük a Time típusú objektumot. 
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A get. time arculat nemcsak idő, hanem dátumok, napok, hónapok és évek 
beolvasására is alkalmas, valamint a dátum elemeinek a sorrendjét is lekér. 
dezhetjük. A fent bemutatott technikákat minimális változtatással alkalmaz. 
hatjuk a num get, num put, money get, money put szabványos arculatok 
használatakor is. Remélhetőleg mielőbb a C-t szabvány része lesz egy dátum., 
idő- és egy pénzosztály, amely a fenti, nem túl egyszerű kódolási megoldások 
alkalmazását csak saját típusok és arculatok esetén teszi szükségessé. 117 

A saját magunk által írt arculattal való együttműködés bemutatásához 
tekintsük meg az alábbi feladatot! 


MET EE TVE TESSEN SE ZRRERÉ EE ES S S t Sez 27 d 
Feladat: írjunk egy sebességet egységbe záró osztályt, amely belső reprezentációként km/h- 


ban tárolja az adatokat. Az osztály legyen képes az amerikai és magyar beállításnak megfelelően 
kiírni és beolvasni a sebességet km/h-ban és mph-ban, ez utóbbi esetén a megfelelő átváltások- 
kal. Az osztály támogassa a közönséges és a széles karaktereket használó adatfolyamokat! 





Megoldás 


A normál és a széles sztringek támogatásához az előző fejezetben megírt ar- 
culatokat át kell alakítanunk sablonokká. Ezt ősosztály esetén az alábbi mó- 
don tehetjük meg: 





Jól látható, hogy az ősosztály esetén a módosítás annyiból áll, hogy sablonná 
tettük az osztályt és a sztring visszatérési típusokat felparamétereztük a 
megadott karaktertípussal. A leszármazottakban már több módosítást kell 


végeznünk: 


"1 Természetesen választhatunk előre megírt osztályt is, például a Boost Ct-t program- 
könyvtárak (http://www.boost.org/) erre is ajánlanak megoldásokat. 
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A példában támogatjuk a széles és közönséges karaktereket, ugyanis a km/h-t 
reprezentáló arculat később például egy német fejlesztésben is jól jöhet. Azért 
tudjuk támogatni mind a közönséges, mind a széles karaktert kezelő adatfo- 
lyamokat sablonosztályokkal, mert a ,km/h" és az ,mph" sztringek mindegyike 
az első 127 kódpontba tartozik, és így megegyezik mind széles, mind közönsé- 
ges karaktert használó esetben. Egyébként külön osztályt kellett volna ír- 
nunk mindkét esetre. Egy konvertálandó karakter esetén használhatjuk az 
adatfolyamok widen és narrow függvényeit, amelyek szűk karakterből készí- 
tenek az adatfolyam karaktertípusának megfelelő karaktert, illetve fordítva.118 
Jelen esetben a tömböt elemenként inicializáljuk (ezt a kérdést a Magyar 
nyelvű szövegfeldolgozás rész tárgyalja részletesen). 
Az amerikai változatban ugyanezeket a módosításokat kell végrehajtanunk: 





"5 Ezek a függvények az adatfolyamhoz rendelt nyelvi környezet etype arculatának a hason- 
Jó nevű függvényeit hívják (lásd Magyar nyelvű szövegfeldolgozás rés2). 
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változó publikus, hiszen tetsző 





séget megadó t: leges valós szám érvényes 
ségérték, A velocity tagváltozóban tárolt sebesség mindig km/h mértékegy. 
ségben értendő. j 
Ezek után meg kell írnunk a kiíró és a beolvasó függvényt. A sablonpa. 
raméterekkel ezúttal ís a basic ostream, illetve a bc istream osztályokat 
példányosítjuk. Elsőként tekintsük meg a kiírást végző operátort: 





sebes 








templatecclass charT, class Traitsz 
std::basic ostreamecharT, Traitsos€ operator cc 
(std::basic.ostreamccharT, Traitsz€ os, const Velocityg v) 
( 
locale loc 5 os.getlocO; 
if (!std::has. facetc velocityccharT: 3(10c)) 
1 
os.setstate(Cios::failbit); 
return os; 


) 


const velocíty ccharT5§ vfacet- 
use. facetc velocityecharTs 5 (10c); 


basic stringccharT: symbol - vfacet.velocity symbolO; 
charT mph(C] — (fm, tpt,th, NO"; 
charT kmh[] — (tkt,otmt, szt, th NO"; 


if(symbol :- mph) 
( 

os cc v.velocity"rO.62; 
) 
else if(symbol -- kmh) 
1 


os cz v.velocity; 

J 

else 

v3 
// Ismeretlen mértékegység 
os.setstate(ios: :failbit); 
return os; 

ii 


// kiírjuk a mértékegységet 
os cc ! ! cc symbol; 

os .width(0) ; 

return os; 


l 








Elsőként lekérdezzük az adatfolyamhoz rendelt nyelvi környezetet, és ellen- 
őrizzük, hogy megvan-e benne a karaktertípusnak megfelelő velocity arculat. 
Ha nincs, az adatfolyam állapotát hibára állítjuk, és visszatérünk. Ellenkező 
esetben viszont lekérdezzük az aktuális mértékegység-szimbólumot. Ha a 
szimbólum km/h, akkor közvetlenül kiírjuk, ha mph, akkor átváltva írjuk ki, 
egyébként hibát adunk, és visszatérünk. Végül kiírjuk a mértékegységet. 
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A beolvasást végző függvény némileg bonyolultabb: 
templatecclass charT, class Traitsz 


std::basic.istreamccharT, Traitss€ operator ss 
(std::basic istreamccharT, Traitssg is, Velocity § v) 
í 


typedef basic stringccharTs string type; 


double d; 

is sz d; 

charT mph(] — ffmt, "pt, th No"; 
charrT kmh[(] — (tk! fm, zt ht NO; 


1ocale loc - is.getloc(); 
if (!Istd::has. facetc velocitycecharTs 5(1oc)) 
; // Ha nincs ílyen arculat 
is.setstate(ios::failbit); 
return is; 
J 


const velocíty -charT:4 vfacetz 

use facetc velocityecharT: 3 (10c); 
string. type symbol - vfacet.velocity  symbol(); 
string.type unit; 


if( symbol -— mph) 
( 
// mph 
is.width(3); 
is 25 unit; 


if(unit !- mph) 


Tt 
is.setstate(ios::failbit); 
else 
( 
// Átváltjuk km/h-ba, 
// mert az a belső formátum 
d z d/0.62; 
J 
J 
úr // (symbol -- kmh) 
77 km/h 
is.width(4); 


ís 55 unit; 
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S ESZÁlÁS 1a kmh) /7/ Ha nem km/h, rossz adat 
is.setstate(ios::failbit); 
hi Tk 
J 


ifCis) // Ha nem volt hiba eddig 
( 
81 v.velocity s d; 


is.width(0) ; 
return is; 


J 


A kezdeti lépések hasonlóak a kiírásnál bemutatottakhoz. Elsőként beolvasunk 
egy lebegőpontos számot. Utána megviz; gáljuk, hogy a nyelvi környezet szerint 
km/h, vagy mph-e az aktuális mértékegység. Ettől függően beolvasunk annyi 
karaktert, amennyi az adott mértékegységhez szükséges. A beolvasott karakte- 
rek számát az adatfolyam width tagfüggvényével állítjuk. A szóközökkel nem 
foglalkozunk, mert a szóköz jellegű karaktereket a bemeneti adatfolyam alap- 
értelmezésben (és ezt rendszerint nem változtatjuk meg) figyelmen kívül hagyja. 
Ha a megadott mértékegység nem megfelelő, az adatfolyam állapotát hibára ál- 
lítjuk. Ha az adatfolyam a műveletek után még hibátlan, akkor az átadott 
Velocity típusú objektumnak beállítjuk értékként. 








12.7. További lehetőségek 


Az eddigiekben ismertettük az STL leggyakrabban használt funkcióit. Az STL 
tartalmaz még néhány lehetőséget, amelyet itt csak megemlítünk. A complex 
fájl tartalmaz egy komplex számot megvalósító osztályt, amelynek sablonpara- 
métere a valós és a képzetes rész típusa, A szabvány specializációt ír elő float, 
double, long double típusokra, amelyek további optimalizálást tesznek lehetővé. 

A valarray osztály egy matematikai értelemben vett vektor, amelyre glo- 
bális függvények segítségével az elemenként végrehajtandó matamatikai mű- 
veleteket megadhatjuk magára a vektorra. Speciális indexelési technikák és 
részhalmazképzés támogatásával hasznos a gyors vektorműveletek progra- 
mozásához. 

A rendszerjellemző numerikus konstansokat a numeric limits sablonosz- 
tály tartalmazza. Itt jelennek meg a numerikus típusok tulajdonságai, például 
a maximális értékek, a lebegőpontos számok exponenseinek hossza, kerekítési 
hibái, végtelenreprezentációi. A sablonparaméter az a típus, amelyről infor- 
mációt szeretnénk lekérdezni (pl.: numeric limitszdoublex::max()). Korábban 
az adatfolyam maximális méretének lekérdezésére használtuk (numeric. li- 
mitséstd::streamsizex::max()). 
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TIZENHARMADIK FEJEZET 


A modellezés és a Ct-r 


Ebben a fejezetben a Unified Modeling Language (egységes modellezőnyelv, 
UML) [18] és a Ct- kapcsolatát tárgyaljuk. Az UML jelentőségét az adja, 
hogy jelenleg az általános szoftverfejlesztés egyetlen szabványos!!? modellező 
nyelve, amelyet szabványossága miatt számos eszköz támogat. Jóllehet az 
eddigiek során arra törekedtünk, hogy a Ct-- bemutatását áthassa az objek- 
tumorientált szemlélet, nem célunk az objektumorientált tervezés és modelle- 
zés részletes ismertetése. Így a számos diagramtípust támogató UML-ből az 
osztálydiagramokat ismertetjük, amelyek az UML leggyakoribb felhasználási 
területét jelentik. Az UML osztálydiagram (UML class diagram) a rend- 
szerben található osztályokat, interfészeket és egyéb típusokat, valamint azok 
kapcsolatát írja le. 

Az UML grafikus modellezőnyelv: a diagramok dobozokból, vonalakból, 
ikonokból és szöveges információból állnak. Az osztálydiagram elemeinek lé- 
nyegi megértéséhez nem szükséges különösebb modellezési jártasság. Elég, 
ha úgy gondolunk egy modellelemre, mint egy gyakran előforduló C--- kód- 
részlet tömör grafikus jelölésére. Ez a tömör grafikus jelölés akkor különösen 
hasznos, amikor egy adott problémát magasabb szinten próbálunk megoldani, 
a teljes megoldás részleteit nem szeretnénk figyelembe venni. Ameddig a do- 
bozok száma és a grafikus modell mérete átlátható, addig a modell által leírt 
megoldás is átlátható. Ezt könyvünk során mi is kihasználtuk: az öröklési hie- 
rarchiákat az UML osztálydiagram jelöléseihez nagyon hasonló módon ábrá- 
zoltuk, így a megoldások reményeink szerint szemléletesebbé váltak. 1 

A továbbiakban bemutatjuk az osztálydiagram elemeit. Először a Git tí- 
pusok modellezését ismertetjük, utána rátérünk a típusok kapcsolatára, a 
sablonosztályok modellezésére, végül pedig a kód és a modell kapcsolatának 
automatizálhatóságával foglalkozunk. Az UML részletes ismertetését például 
[17118] irodalmakban találhatjuk. 


TT ű Ti, jelen- 
19 Az UML szabványosítási folyamatát az Object Management Helye KEKZÓ Meta NégE 
leg az UML 2.1.1 verzió a legfrissebb. Az UML szabvány szabadon letöl 
címről, 
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13.1. Osztályok 





Az osztálydiagram legfontosabb elemei az osztályok, amelyeket téglalap jelöl. 
Ez a téglalap három fő szakaszra oszlik: a legfelső szakasz tartalmazza az 
osztály nevét, a középső az osztály attribútumait (attribute), a legalsó szakasz 
pedig az osztály műveleteit (operation). Az osztály attribútumai a C-t tagvál- 
tozóknak felelnek meg, a műveletei pedig a C-t tagfüggvényeknek. Az alsó 
két szakaszt nem mindig szeretnénk megjeleníteni, ezek egyenként , össze- 
nyomhatók", vagyis a modellezőeszközök lehetővé teszik, hogy ezek nélkül je- 
lenítsük meg az osztályt. Az osztály jelölésére a következő ábra mutat példát: 


Rectangle 


a: double-00 
b. double 00 
area: double 





4. Seta(double) : void 
4. Setbídouble) . vid 











33. ábra. Osztály jelölése 
Egy osztály attribútumait az alábbi szintaxissal adhatjuk meg: 
láthatóság név: típus multiplicitás - alapértelmezett érték ftulajdonságok) 
Például egy négyzet konstans oldala esetén: 
- a:double[1] - 0.0 freadOnly) 

Ezek közül csak a név a kötelező. A láthatóság négyféle lehet: 

e 4: public 

e — -: private 

e — ft: protected 

e. —: package (Ct--ban nincs ilyen) 


A láthatóság és a név közé elhelyezett opcionális perjellel a származtatott att- 
ribútumokat jelöljük. Egy téglalap esetén, ha nemcsak az oldalakat tároljuk 
attribútumokban, hanem a területet is, akkor a terület származtatott attribú- 
tum, hiszen ki lehet számolni az oldalakból. A származtatott tagváltozókat a 
C4-4 kódban nem jelöljük. Ha valami oknál fogva lényeges, akkor komment- 
ben megadhatjuk. Ez például akkor lehet fontos, amikor az osztály egy objek- 
tumát relációs adatbázisban akarjuk tárolni, ahol a számítás komplexitásától 
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függően nem tároljuk el a redundáns származtatott értékeket, hanem a le. 
kérdezés után újra kiszámoljuk. Az attribútum nevét kettőspont követi, ahol 
megadjuk az attribútum típusát. 

Ha az attribútum tömb, akkor a multiplicitás adja meg a tartalmazott 
elemek lehetséges számának a halmazát. A multiplicitás egy egész szám vagy 
egy egészekből álló intervallum, amely szövegként jeleníthető meg. Az inter- 
vallum szintaxisa: alsó határ..felső határ, Az alábbiakban mutatunk néhány 
általános példát: 


e — 0..1(0 vagy egy) 

e — 1 (pontosan egy) 

e — 0.." (nulla vagy több) 
e — "(nulla vagy több) 

e. ".." (nulla vagy több) 
e — 1.." (egy vagy több) 
1..6 (egytől hatig) 


Ha nem adunk meg multiplicitást, akkor az alapértelmezett a pontosan egy. 
Ezért a négyzet konstans oldalát egyszerűbb formában is írhatjuk: 


- a:double - 0.0 freadOnly) 


Ctt tömbök esetén az alábbi két eset értelmes: 
e  0..n 


etek 


Az első esetben az n konkrét számérték. Ezt C-t--ban statikus tömbként való- 
sítjuk meg. A második esetben dinamikus tömböt, például az STL vector osz- 


tályát használhatjuk. ÉRŐ EDTAKEN 
Az alapértelmezett értéket C-t4-ban a konstruktor inicializálási listájá- 


ban adjuk meg. Az UML szabvány szerint egy attribútumnak kapcsos záró- 
jelben további tulajdonságokat is megadhatunk. A konstans attribútumot a 
példának megfelelően readOnly tulajdonsággal jelöljük. A statikus attribú- 
tumot aláhúzás jelöli. 

A műveleteket a következő szintaxissal adhatjuk meg: 


láthatóság név paraméterlista: visszatérési. érték (tulajdonságok? 
Például egy téglalap a oldalát beállító függvényt az alábbi módon írhatunk le: 
4 Seta(a:double):void 
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A láthatóság ugyanaz, mint az attribútumok esetén, a név a művelet neve, 
A paraméterlista szintaxisa a következő: 


irány név:típus - alapértelmezett érték 


Az irány háromféle érték lehet: 
e. in: bemenő paraméter 
s. out: csak kimenő paraméter 


s. inout: bemenő és kimenő paraméter 


Ha nem írunk irányt, akkor az in az alapértelmezett. 0-t4-ban az in az érték 
szerinti paraméterátadásnak felel meg, míg a másik kettő esetében referenciát 
vagy nagyon ritkán pointert adunk át. Az inout azt jelzi, hogy a függvény fel. 
használja a referencia vagy a pointer által jelzett objektumot és meg is változ- 
tatja, míg az out esetében csak megváltoztatja. 

A C44 konstans tagfüggvényt a művelet fguery) tulajdonságával adhatjuk 
meg: 





t Geta(out a:double):void fguery) 


A statikus műveleteket a tagváltozókhoz hasonlóan aláhúzással jelöljük. A tisz- 
tán virtuális függvényeket vagy dőlt betűvel, vagy az fabstract) tulajdonsággal 
adhatjuk meg, Ilyenkor az osztályt is absztraktnak nevezzük, és megjelöljük az 
fabstract) tulajdonsággal a névszakaszban, vagy a nevét dőlttel jelenítjük meg. 
Ha minden művelet absztrakt, és az osztálynak nincs attribútuma, akkor az 
osztályt a névszakaszban az cginterfacez5 kulcsszóval látjuk el. Ilyenkor az 
osztályt interfésznek hívjuk. Az interfész a C-4-t-ban nem nyelvi elem, csak tisz- 
tán virtuális tagfüggvényeket tartalmazó osztállyal valósítjuk meg, amelynek 
nincs tagváltozója. 

A struktúrákat a cSstruct22 kulcsszóval jelöljük az osztály névszakaszá- 
ban, az enum típust pedig az csenumeration:2 kulcsszóval. 





13.2. Kapcsolatok 


Az eddigiekben sorra vettük az alapelemeket és C--r-beli megjelenésüket. 
Ezek a modellelemek csomópontként jelennek meg a modellekben. Ebben a 
fejezetben azokat az elemeket tárgyaljuk, amelyek élként jelennek meg a mo- 
dellben összekötve a csomópontokat. 

Az egyfajta kapcsolatot részletesen ismertettük a 3.1. és a 7. fejezetben. 
Ezt a kapcsolatot az eddigiekkel összhangban az UML is üresháromszög-fejű 
nyíllal jelöli. 
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13.2. Kapcsolatok 
13.2.1. Asszociációk 


Tekintsük meg az alábbi UML osztálydiagramot! 





34. ábra. UML osztálydiagram az asszociációk bemutatására 


Példánkban egy szállásfoglaló rendszer egy részletét látjuk. A vendég (Custo- 
mer) a weben keresztül megad egy foglalást (Reservation), amelyhez egy számla 
(Bill), tartozik. A foglaláshoz legalább egy szállás (Accommodation) tartozik, 
amely absztrakt osztály. Egy szállás lehet szoba (Room), lakosztály (Suite) vagy 
apartman (Apartment). 

Vizsgáljuk meg a számla és a foglalás kapcsolatát! Amikor egy vendég beje- 
lentkezik a szállodába, akkor a recepciósnak szüksége van arra az információra, 
hogy a vendég előre fizetett, esetleg postán már elküldték neki a számlát, vagy 
majd az ott-tartózkodás végén szeretné megkapni. Ez azt jelenti, hogy a Reser- 
vation osztály objektumaiból el kell érnünk a hozzájuk tartozó Bill típusú objek- 
tumot, Amikor viszont a szálloda pénzügyeit intézik, akkor a számlák alapján 
szükség lehet arra, hogy visszakeressék a foglalást. Vagyis a Bill típusú objek- 
tumokból el szeretnénk érni a hozzá tartozó Reservation típusú objektumot. Az 
UML-ben az ilyen jellegű kapcsolatot asszociációnak (association) nevezzük. 
Az asszociációt általánosságban egy vonallal jelöljük. Erre a vonalra égvázdgató 
ZÉpre az asszociáció neve. A Reservation és az Accommodation is asszociációval 
kapcsolódik egymáshoz, Az asszociáció neve itt egy igei szerkezet (a foglalás le- 
foglalja a szállást, reserves), és mivel ennek iránya nem mindig egyértelmű, nyíl- 
fej jelöli, hogy a foglalás foglalja le a szállást, és nem fordítva. 
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13. fejezet: A modellezés és a Cs 


A Reservation és a Bill közötti összefüggésnél a , foglaláshoz tartozó számla?" 
lenne a kifejezés, viszont a kapcsolódás tényét maga az asszociáció jelenti, 
Semmitmondó nevekkel nem érdemes bonyolítani a modellt, így a nevet ezen 





Az asszociációkhoz az asszociáció nevén kívül két szerepnév (role name) 
is tartozhat, amely azt mutatja meg, miként vesz részt az adott osztály az 
asszociációban. Például a személy munkavállalóként (employee) vesz részt a 
céggel való kapcsolatban, míg a cég munkáltatóként (employer). 





"EMPIRE ugáefor me "employer 





35. ábra, A személy-cég kapcsolat 


Az asszociációnak van még egy nagyon fontos tulajdonsága. Ha az előbbi példá- 
ban nem feltételezünk másodállást, akkor egy személy egy cégnek dolgozik. Vi. 
szont egy cégnek több alkalmazottja lehet, tegyük fel, hogy legalább kettő szük- 
séges a cégalapításhoz. Ezt kifejezendő nemcsak az attribútumokhoz, hanem az 
asszociáció végpontjaihoz is tartozik multiplicitás. Az asszociáció multiplicitá- 
sát az alábbi mondat kiegészítésével értelmezhetjük és állapíthatjuk meg: 


e Egy X típusú objektumhoz hány Y típusú objektum tartozhat az asszo- 
ciáción keresztül? (Az asszociáció Y oldali végpontjának multiplicitása) 


e Egy Y típusú objektumhoz hány X típusú objektum tartozhat az asszo- 
ciáción keresztül? (Az asszociáció X oldali végpontjának multiplicitása) 


Szállodás példákon ez a következőképpen jelenik meg: 


. Egy vendéghez legalább egy foglalás tartozik (a Reservation oldali 
multiplicitás 7.."), illetve egy foglaláshoz pontosan egy vendég tarto- 
zik (feltételezzük, hogy a többszemélyes foglalások is egy vendég ne- 
vén vannak). A pontosan egy multiplicitás az alapértelmezett, ezt itt 
sem jelöljük külön. 


. — Egy foglaláshoz több szállás is tartozhat (utazási iroda végzi a foglalást), 
de egy mindenképpen, illetve egy szálláshoz több foglalás is tartozhat (ha 
felszabadul a szoba, más foglaláshoz rendelik). Ezért az Accommodation 
oldali multiplicitás 7..", a Reservation oldali multiplicitás 0..". 


. — Egy foglalást nem lehet több számlán kérni, így egy foglaláshoz egy 
számla kapcsolódhat, illetve egy számlán csak egy foglalás szerepel- 
het. Viszont előfordul, hogy a foglalás már létrejött, de számlát csak 
később készítenek hozzá, így megengedjük, hogy egy foglaláshoz nulla 
vagy egy számla tartozzon. 





Miután végigvettük az asszociáció tulajdonságait a m izsgálj 
géz hogy a Ct- kód szintjén hogyan jelenik lot Meola Tejosávlbvgosa 

Vegyük elsőként a Reservation és a Bill közötti asszociációt! 
táció szempontjából elsőként arra gondolhatnánk, hogy a Reseru 
nak legyen egy Bill típusú tagváltozója, illetve a Bill-nek egy Reseri 
pointere, amelyet a konstruktorában vár inicializáláskor, 
oda-vissza hivatkozást. 


Az implemen- 
Jation osztály: 
vation típusú 
és így megoldottuk az 


class Reservation; A 





class Bill 
1 






Reservationt reservation; 
public: ZAY 
Bill(Reservation § r):reservation(r)íp mi 
Reservation" GetReservationOconst ífreturn res 
h 


class Reservation 


ÉL 

BÍI1 bill; 
public: 

Reservation() :bili(this)() 

const Bill" GetBillOconstíreturn ébill;) 7 
jú EKB 


Ez csak speciális esetekben lehet jó megoldás, általánosságban nem. Pél- 
dánkban ugyanis a pénzügyi modul írásakor nem szeretnénk végigiterálni 
minden egyes foglaláson, és lekérdezni a hozzá tartozó számlákat. Az ideális 
eset az lenne, ha lenne egy foglaláslista, amely elvégezné a foglalásokhoz tar- 
tozó memóriafoglalást és -felszabadítást, valamint lenne egy számlalista, 
amely a számlákhoz kapcsolódóan végezné el ugyanezt a feladatot. Sokszor 
teljesül, hogy a foglalásnak és a számlának is van egyedi azonosítója. Így a 
számlában eltárolva a foglalás azonosítóját, illetve a foglalásban a számláét 
összerendelhetnénk a két objektumot. Ekkor azonban az azonosító alapján a 
másik listában meg kellene keresni az adott azonosítójú objektumot. Jobb 
lenne, ha referencián vagy pointeren keresztül közvetlenül hivatkoznánk a 
másik objektumra. Mivel C--4-ban a referenciát inicializálni kell, és utána 
nem rendelhetjük más objektumhoz, ezt a megoldást csak akkor választhat- 
juk, ha az összerendeléskor már mindegyik objektum létrejött, és az OSSZe- 
rendelés a két objektum élettartama során nem változik. Ráadásul, ha 68 
rencia típusú tagváltozóval dolgozunk, nem generálódik alapértelmezett s 
Operátor, A gondolatmenet eredményét az alábbi módon össz egezhetjük: gp" 

A Reservation osztályban egy Bill típusú pointerrel valósítjuk meg az dl 
Szerendelést. Mivel létezik olyan időpont, amikor egy foglaláshoz nem tarto 
zik egy számla sem, ezért írunk olyan metódust, amely beállítja a Bill típusú 
Porntert, 


433 














13. fejezet: A modellezés és a Ctr 





Mivel a számla létrehozásakor már létezik a hozzá tartozó foglalás, ezért a 
Bill osztályban egy Reservation típusú pointert már a konstruktorban átvegz. 
szük, és a konstruktor törzsében hozzárendeljük az objektumot a Reservation 
paraméterhez. Mivel az erendelés nem változik az objektum élettartama 
során, nem írunk olyan függvényt, amely változtatni tudja a pointer értékét, 





class Bill; 
class Reservation 


BÍTT" bill; 
public: 
Reservation() :bi 1I(NULL) í? 
const Bill" GetBillOconstíreturn bíll;?) 
void SetBill(Bil1" pb)íbill - pb;) 
bi 


class BÍTl 
t 
Reservationt reservation; 
public: 
BÍTI( Reservation " r):reservation(r)(r-sSetBill(this);) 
Reservationt GetReservation()const íreturn reservation;) 
hi 


Ezek után felépíthetünk két külön tömböt, és az egyes tömbelemek esetén 
használhatjuk az összerendelést egymás gyors elérése végett. 


std 
std 





: :vectorcReservation; reservations; 
::vectorcBill: bills; 


// Foglalás számla nélkül 
Reservation r; 
reservations push back(r); 


// Foglalás számlával 
Reservation r2; 
Bill b(ér2); 


reservations .push  back(r2) ; ; 
bi11s.push. back(b) ; v 


Fontos, hogy a Reservation esetében figyelnünk kell arra, hogy a pbill tagvál- 
tozó, így a GetBill tagfüggvény értéke is lehet NULL. Érdemes észrevenni, 
hogy bá objektumok pointereken keresztül érik el egymást, nem ők a fele- 
lősek a m objektum memóriaterületének lefoglalásáért. A pointerek mind- 
össze arra szolgálnak, hogy a két objektum gyorsan elérje egymást. Könnyen 
lehet — és a példában is ez a helyzet —, hogy nem is dinamikusan foglaltuk az 
objektumokat. Ezért ezeket a pointereket nem szabadítjuk fel sem a destruk- 
torban, sem más tagfüggvényben. A példában szerzett tapasztalatokat a tag- 
változókra koncentrálva az alábbi módon általánosíthatjuk. 
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13.2. Kapcsolatok 


Útmutató: Az asszociációk Css-beli megvalósítása 1, illetve 0..1 esetén az alábbi módon történik; E] 


— Létrehozunk az egyes osztályokban egy-egy pointert, melynek tíj ket 
évő á A 9 típusa az ? 
sik oldalán lévő osztály, neve a másik oldalon lévő szerepnév. jögijás sss sg 








— Ha a nulla multiplicitás is megengedett az asszociáció másik oldal 


A pazft lán, akkor fel é- 
szülnünk rá, hogy a pointer értéke NULL is lehet. St MEREM 


Ez azt jelenti, hogy a szerepnevek és a multiplicitásértékek a kódban az UML 
diagramhoz képest , keresztben" helyezkednek el: 


mezerten] evente Es] 
szt isszészáz 51] 
Br] Ces ezzseéri 


ciass Reservation 
kj 

// Lehet NULL 
Bill" bill; 














Reservationt reservation; 


hi 








36. ábra. Kétirányú ! és 0..1 multiplicitású asszociációk leképezése C4- kódra 


Jól látható, hogy a szerepnév előtt egy ,,-" jel látható. Ez a szerepnévből képződő 
tagváltozó láthatóságát jelenti az attribútumoknál megadott módon: példáink- 
ban a ,- jel miatt ezek a változók privát láthatóságúak. A multiplicitást is ha- 
sonlóan érdemes elképzelnünk: jóllehet az asszociáció Bill oldalán engedélyez- 
zük a nulla multiplicitást, mivel a szerepnévből képzett pointer a Reservation 
osztályban jelenik meg, ezért a NULL értékre is ott kell odafigyelnünk. 

A CH kód fényében az asszociációk végén található nyilat is értelmezni 
tudjuk. Egy adott oldalon az UML eszközök az asszociáció egy végpontjához 
akkor rajzolnak ki nyilat, ha a végpont Navigable (navigálható) tulajdonsága 
igazra van állítva. Ez azt jelenti, hogy a nyíl által kijelölt irányban átjárható 
az asszociáció. Az átjárhatóságot a kódban egy pointer létrehozása jelenti. 
Ezért a pointer csak akkor jelenik meg a kódban, hogyha az asszociáció sze- 
repnévhez tartozó végpontján a Navigable tulajdonság igaz. Ha csak a Reser- 
vation típusú objektumokból szeretnénk elérni a foglaláshoz tartozó számlá- 
kat, fordítva nem, akkor azt az alábbi módon jelöljük: 


435 














13. fejezet: A modellezés és a Css 








class Reservation 
ú class Bill 


// Lehet NULL u 
Billt bill; 


1; 





37. ábra. Egyirányú asszociáció leképezése C44 kódra 


Nézzük meg ezek után a Customer és a Reservation közti asszociációt! A Reser- 
vation osztályban az eddig bemutatott módon egy Customer típusú pointer je- 
lenik meg, melynek neve customer, láthatósága privát. A Customer osztály 
esetén más a helyzet. Mivel itt egy vendéghez több foglalás is tartozhat, ezért 
egy pointer nem elég, pointerek tömbjére van szükség. Mivel felső határt nem 
adtunk meg (a " tetszőleges számú foglalást jelöl), statikus tömb nem elég, 
így dinamikus tömböt választunk:120 





"9 Az asszociációt implementáló tömbnek alapértelmezésben egyedi elemeket kell tartal- 
maznia, és tetszőleges sorrendben adhatják vissza a pointereket. Általában az egyedisé- 
get nem szokták ellenőrizni. Ha ez mégis fontos, akkor használhatunk set-et vagy nem 
szabványos has set-et, esetleg beszúráskor ellenőrizhetjük, hogy szerepel-e már a be- 
szúrandó elem a tömbben. Ha az asszociáció végpontján szerepel az fordered/ kényszer, 
akkor a tömbnek rendezettnek kell lennie. Ehhez használhatunk rendezett vektort, ame- 
lyet minden beszúrásnál rendezünk, vagy set osztályt. Van, amikor az forderedj kényszer 
csak annyit jelent, hogy a beszúrás sorrendjét kell megőrizni. Ilyenkor egy vector tökéle- 
tesen megteszi, ha az elemeket a végére szúrjuk be, és az elejéről vesszük ki, bár a gueue 
tárolóadapter nagyobb biztonságot nyújt. A fnonuniguej kényszer esetén egy elem tőbb- 
meeemeezépelhet, Ilyenkor rendezetlen esetben vector-t, rendezett esetben multiset-et 
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A példában néhány gyakori függvényt is bemutattunk. Ha a vendég új foglalást 
kér, akkor az új Reservation típusú objektumot feliratkoztatjuk a Customer ob- 
jektum listájára az AddReservation tagfüggvénnyel. Ha el akarjuk távolítani, a 
RemoveReservation tagfüggvényt használhatjuk. A fenti implementáció cím 
szerinti összehasonlítást végez, mivel pointereket tárolunk a tömbben. A List- 
Reservation bemutatja a tömb használatát, vagyis az adott vendéghez tartozó 
foglalások kiírását. Ha nagyobb hozzáférést szeretnénk biztosítani az asszociá- 
ciót implementáló tömbhöz, akkor tegyük publikussá, ami az osztálydiagram- 
ban a szerepnév láthatóságának publikusra való módosítását jelenti. 





Útmutató: Az asszociáció végpontjának felülről nem korlátos multiplicítását Csr-ban pointe- 
rek dinamikus tömbjeként valósítjuk meg. A tömb neve a multiplicításhoz tartozó szerepnév, 
láthatósága a szerepnévnél jelölt láthatóság. A felülről korlátos multiplicitást statikus tömbbel 
is megvalósíthatjuk. 


Vizsgáljuk meg most a Reservation és az Accommodation között lévő reserves 
nevű asszociációt! A több-több kapcsolat nem hordoz különösebb újdonságot, 
mindkét oldalon dinamikus tömbbel implementáljuk. Itt a 0 multiplicitás is 
kevesebb problémát okoz: míg a 0..1 esetben mindig ellenőrizni kellett, hogy a 
pointer értéke nem NULL, a 0.." esetben például a Customernél bemutatott 
tömbbejáró ciklusok törzse egyszerűen nem fut le az üres tömb esetén, vagyis 
még esetszétválasztásra sem volt szükség. Í 

úg reserves asszociáció ugyanakkor egy nagyon fontos esetre mutat ges 
A Reservation osztályban az alábbi tömb felel meg a reserves asszociációnak: 
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13. fejezet: A modellezés és a Cst 





Az osztálydiagramon látható, hogy az Accommodation dőlt betűvel van szedve, 
vagyis absztrakt osztály, amelyet nem példányosíthatunk. C-t-tszemmel nézve 
van legalább tisztán virtuális függvénye. Ezért például az AddAccommodation 
tagfüggvénynek átadott Accommodation típusú pointer mögött vagy Room, 
vagy Suite, vagy Apartment típusú objektum található, ezért az accommoda- 
tions vektor heterogén kollekció lesz, vagyis polimorf viselkedésre számítunk. 
Ugyanakkor a polimorfizmus C-t--ban csak pointerre és referenciára működik. 
A referenciák fentebb részletezett hátrányos tulajdonságai miatt az asszociáció- 
kat C:-4-ban pointerekkel szokás implementálni. 





Útmutató: Az asszociációt implementáljuk pointerekkel, így a diagram új leszármazottakkal 
való kiegészítése nem jár a már elkészített kód komolyabb megváltoztatásával, és a referencia 
hátrányait is elkerüljük. 





A diagramot tovább tanulmányozva azt is észrevehetjük, hogy az örökléssel 
implementált általánosítás miatt az accommodations vektor és az azt kezelő 
függvények szintén megtalálhatók a vagy Room, vagy Suite, vagy Apartment 
osztályokban, jóllehet a vektor a privát láthatósága miatt nem elérhető. Vagyis 
az UML diagramban az Accommodation ősosztályból kiinduló asszociáció 
nemcsak az őst, hanem a leszármazottakat is összeköti a reserves asszociáción 
keresztül a Reservation osztállyal. Ez az asszociáció mentén fordított irány- 
ban is igaz, azzal a megkötéssel, hogy a leszármazott osztályok csak az ősosz- 
tály interfészén keresztül érhetők el. Ez a C--- kódon jól látható, ugyanis az 
accommodations tömb Accommodation típusú pointereket tárol. 

Az eddigiekben a több multiplicitást dinamikus tömbökkel implementál- 
tuk. Az alábbi ábra új példaként szemlélteti a kurzus és a kurzusra járó hall- 
gatók közötti egy-több asszociációt. Jelen példában csak azt szeretnénk tudni, 
hogy egy kurzusra milyen hallgatók járnak, azt nem, hogy egy hallgató mi- 
lyen kurzusokat látogat. Ezért a kapcsolat egyirányú asszociáció. 





38. ábra. Egy-több kapcsolat a kurzus és a hallgatók között 
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Ugyanakkor várható, hogy sokszor lesz szüksé 
hogy egy adott azonosítójú hallgató jár- 
nénk a Course osztály tagfüggvényeiből 
kat. De állandóan végigkeresni a dinamikus tömböt, és megvizsgálni hogy az 
adott hallgató azonosítója megegyezik-e a keresett azonosítóval nem Tardi a 
leggyorsabb megoldás. Ilyen esetben asszociatív tömböt használunk. amely- 
nek kulcsa a hallgató azonosítója. Ennei 4 
asszociáció (gualified association). 

A minősített asszociáció két osztály között teremt kapcsolatot egy minő- 
sítőn (gualifier) keresztül. A minősítőt az asszociáció egyik oldalára rajzolt 
téglalapban elhelyezett nevével jelöljük. A minősítő az asszociáció másik olda- 
lán lévő osztálynak egy vagy több attribútuma. 


günk arra az információra, 
e a kurzusra, illetve sokszor szeret- 
azonosító alapján elérni a hallgató- 


k modellezésére szolgál a minősített 


students 





39. ábra. Az ID minősítő a kurzus-hallgató asszociációban 


A minősítőt a példánkban map-pel implementáljuk (a nem szabványos hash map 
gyorsabb megoldás lehet): 


class Student 


( 


string ID; 


class Course 


í 
public: 
mapcstring, Student"5 students; 


Figyeljük meg, hogy a minősítő bevezetésével az 1.." multiplicitást felváltotta 
az 1 multiplicitás. Ennek az az oka, hogy minősített asszociáció esetén a mi- 
nősítőhöz viszonyítjuk a multiplicitást: egy hallgató azonosítójához egy hall. 
gató tartozik, mert az azonosító egyedi. Ebből a szempontból a minősítő Gő 
kenti a multiplicitásokat, mint ahogy azt a példánkban is tette. Ha a ösgznt 
esetén is többszörös a multiplicitás, akkor multimap-et használhatunk, aho! 
két elem is szerepelhet ekvivalens kulccsal. ek 
Néha SJ olyan helyzet, amikor egy attribútum nem KEZEK sének 
egyik osztályhoz sem, hanem inkább az assz ciáció false Al KS LSE 8 
kissé változtattunk az eddigi Person-Company modellen: Hl step ági 
másodállás lehetőségét. A kérdés, hogy ilyenkor hova írjuk a fizetést (5 1), 














439 














13. fejezet: A modellezés és a Crr 


illetve a beosztást (job title). Egyfelől ez a két attribútum nem tartozik sem a 
személyhez, sem a céghez. Ezek inkább a kettőjük kapcsolatát kifejező asszo- 
ciáció attribútumai. Másfelől az a probléma, hogy mindkettőből több lehet: 
ahány másodállása van a személynek, annyi fizetése és beosztása van. 


temployee  gogetor  temployer Company 


JobParameters 


-  jobTitle: string 
-  Ssalary: fioat 





40. ábra. Asszociációs osztály 


Az asszociáció attribútumait egy új konstrukció, az asszociációs osztály 
(association class) modellezi, amelyet az asszociációhoz szaggatott vonallal 
kapcsolt osztály jelöl. Példánkban ez a JobParameters nevű osztályt jelenti. 
Egy bizonyos Person típusú objektumból és Company típusú objektumbáól álló 
párosra egyetlen asszociációsosztály-példány létezik. Vagyis minden egyes 
alkalmazott-állás pároshoz tartozik egy objektum, amely megmondja a fize- 
tést és a beosztást. 

Az asszociációs osztályt osztályként implementáljuk, benne két pointer- 
rel, amely a bal, illetve a jobb oldali osztályra mutat: 





Az asszociációban részt vevő két osztályban ezúttal az asszociációs osztályok- 
ra mutató pointert vagy pointertömböt tárolunk a multiplicitásnak megfele- 
lően. Ugyanakkor a másik oldal objektumainak elérését is megkönnyítjük egy 
függvénnyel: lekérdezzük az asszociációs osztályokat és összegyűjtjük a má- 
sik oldali objektumokat. 








A megoldás azért rugalmas, mert ha az osztály felhasználójának a másik oldal 
objektumai kellenek, ahhoz is egyszerűen fér hozzá, és ha kíváncsi az asszociá- 
ciós osztály objektumában tárolt adatokra, ahhoz is hozzáférhet. A Company 
osztályt teljesen analóg módon implementáljuk. 

A fentiekben láttuk, hogy az asszociációt tagváltozókkal valósítottuk meg. 
Felmerülhet a kérdés, miért nem használunk attribútumokat a modell szint- 
jén is. Ebben a modell áttekinthetősége és olvashatósága dönt, nehéz éles ha- 
tárt vonni, hogy mikor melyik modellelemet válasszuk. Az eddigi példák ese- 
tében többnyire asszociációval modelleztük az osztályok kapcsolatát, ez sok- 
kal áttekinthetőbb, mint a platformfüggő tömbneveket tartalmazó osztályok. 
Ugyanakkor a string osztállyal való kapcsolatot célszerűbb attribútumként 
megadni, mint asszociációval, mert ebben az esetben ez az átláthatóbb meg- 
oldás. Mivel az asszociációkat pointerrel implementáljuk, ezért az objektum- 
tagváltozókat attribútumként modellezzük. 

Az asszociációnak van két specializált fajtája, nevezetesen az aggregáció 
(aggregation) és a kompozíció (composition). Az aggregáció olyan asszociá- 
ció, amely tartalmazást jelöl, jele a tartalmazó oldalán egy üres rombusz. Pél- 
dául egy vállalat egy vagy több részleget tartalmaz. 





41. ábra, A vállalatnak egy vagy több részlege van 
A tartalmazás a generált kódban nem jelenik meg, és tulajdonképpen az a57- 


szociáció jelentéséhez sem tesz hozzá túl sokat. Az aggregációt sokan sem- 
mitmondónak tekintik, és nem javasolják a használatát [17]. 
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A kompozíció jelölése abban különbözik a tartalmazásétól, hogy a rom. 
busz nem űres, 


3." (ordered) 





42. ábra. A sokszög pontokat tartalmaz (kompozíció) 


Az ábrán látható sokszög pontokat tartalmaz, legalább hármat, és a pontok 
sorrendje számít. A kompozíció két fontos kényszert jelöl: 

Kompozíció esetén a tartalmazott objektum pontosan egy tartalmazó ob. 
jektumhoz tartozik, vagyis a tartalmazott objektum nem lehet megosztva, 

Kompozíció esetén a tartalmazó és a tartalmazott együtt jön létre, és 
együtt szűnik meg. A tartalmazott objektumért mint erőforrásért a tartalma- 
zott felel, így a felszabadításáért is, 

Általánosságban a kompozíciót ugyanúgy implementáljuk, mint az asszo- 
ciációt, de ilyenkor a destruktorban meg kell írnunk a felszabadító kódot (és 
sokszor a konstruktorban a létrehozó kódrészletet). Ha a tartalmazott objek- 
tumból biztosan nem származik semmi, a kompozíciót implementálhatjuk po- 
inter helyett objektumként, amely tagváltozóként vagy statikus/dinamikus 
tömb tagváltozóként jelenik meg. 


13.2.2. Sablonok modellezése 


Ebben a fejezetben az osztálysablonok modellezését mutatjuk be. Az UML el- 
viekben képes műveletsablonok létrehozására is, de erre még nincs a gyakor- 
latban ís elfogadott, széles körű megoldás. Az osztálysablonoknál két dolgot 
kell modelleznünk: az egyik a sablonparaméter jelölése, a másik a sablonpa- 
raméter és a hozzárendelt konkrét példányosítás összerendelése, 

Az osztálysablonok sablonparamétereit az osztály jobb felső sarkában elhe- 
lyezett, szaggatott vonalú téglalapban soroljuk fel. Ha a sablonparaméternek 
van alapértelmezett értéke, akkor a C-t szintaktikához hasonlóan egyenlőség- 
jel után adjuk meg. A típusos konstansokat név:típuszalapértelmezett érték 
szintaktikával jelöljük Az alábbi ábrán az STL vector osztály sablondefinícióját 
modelleztük. 


íT 





vector 


43. ábra. A vector sablon 
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13.3. Kódgenerálás és kódvisszafejtés 


A sablonok kifejtését vagy példányosítását kétfélei 


képpen modellezhetji 
egyszerűbb jelölés az osztály neve után kettőspon zdékezátási 


ttal elválasztva feltünteti a 


példányosítást. munek ezintaxisa a következő: sablonosztálycsablonparamé. 
ter2kötött-paraméter. Ha több sablonparaméter-kötöttparaméter páros van, 
akkor vesszővel választjuk el őket. Az alábbiakba. . 
sal példányosítjuk. 


n a vector sablont int típus- 





44. ábra. Sablonpéldányosítás az osztálynévben 


Mivel az Allocator paramétert nem kötöttük semmilyen elemhez, az alapér- 
telmezett értékével fog példányosulni. 

A másik megoldás, hogy a paraméterkötésre külön jelölést használunk: 
egy üresháromszög-fejű szaggatott nyilat, amelynek speciális funkcióját a 
ssbind2? kulcsszóval jelöljük meg. A sablonparaméter kötését a nyílon adjuk 
meg az előző szintaktikával. 





eType.sint: 


abindp 


IntVector 


45. ábra, Sablonpéldányosítás ccbindz5 kulcsszóval 


13.3. Kódgenerálás és kódvisszafejtés 


Az UML nyelvű modellezés akkor igazán hatékony, ha a modellek netezek 
dokumentációs célokat szolgálnak, hanem automatikusan kódot is SZAVAS ER 
lólük generálni, A fent bemutatott modell-kód megfeleltetés level me öt 
Bében jól automatizálható. Az eszköztámogatás szempontjából BEJOSZEKT he 
ram különösen szerencsés: szinte mindegyik UML eszköz Kétes Kukét. 
rálni az osztálydiagram elemeiből. Ebben a fejezetben összefoglalju 

irányú generálás alapfogalmait. 
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Fgá 


Modgellezés 


46. ábra. Kétirányú generálás 


Feladattól és eszköztípustól függően a fejlesztés vagy a kódolással, vagy a mo- 
dellezéssel kezdődik. A modellező eszközök támogatják az átjárhatóságot: mo. 
dellből képesek kódot készíteni, valamint kódból képesek modelleket előállíta- 
ni. Az előbbit kódgenerálásnak (forward engineering, code generation) nevez- 
zük, az utóbbit kódvisszafejtésnek (reverse engineering). A két szolgáltatást 
együtt kétirányú generálásnak (round-trip engineering) hívjuk (46. ábra). 

Amennyiben a kódgenerálás figyelembe veszi a már létező kódot, és csak 
a különbséget vezeti át, akkor modell-kód szinkronizálásról (model-code 
synchronization) beszélünk. Az ellenkező irányú folyamat neve kód-modell 
szinkronizálás (code-model synchronization). 

Az UML osztálydiagram kontextusában jelenleg mindez azt jelenti, hogy 
a kódgenerátorok képesek legenerálni az osztálydeklarációt, a megadott és az 
asszociációkat megvalósító tagváltozókat, valamint a függvények fejlécét, de a 
függvénytörzseket üresen hagyják. Ha az eszköz modell-kód szinkronizálást 
is támogat, akkor a megváltoztatott kódot (jellemzően a kitöltött függvénytör- 
zset) nem írja felül az újabb kódgenerálási folyamat. Ezt a feladatot számos 
eszköz kommentben elhelyezett azonosítók segítségével oldja meg. A visszafe- 
le irány általában teljes mértékben támogatott: az UML osztálydiagramot 
szinte minden eszköz képes előállítani a programkódból. A kód-modell szink- 
ronizálást támogató eszközök itt is csak a különbséget vezetik át. Azok az 
eszközök, amelyek nem támogatják az automatikus modellelrendezést, ezek 
után még elég sok munkát hagynak a felhasználónak, amíg olvashatóvá tudja 
rendezni a modellt. 





TIZENNEGYEDIK FEJEZET 


Esettanulmány 


A fejezetben egy nagyobb lélegzetű esettanulmányt dolgozunk ki, amelynek cél- 
jaa fontosabb CH nyelvi elemek bemutatása egy összetettebb feladaton. A fel- 
adat megoldásának középpontjában az egyik legfontosabb objektumori entált 
nyelvi eszköz, az öröklés és a virtuális függvények megfelelő alkalmazása áll. 
Elsőként egy olyan megoldást fejtünk ki, amelyhez nem szükségesek a 
könyv haladóbbaknak szóló fejezeteiben szereplő ismeretek. Utána megmutat- 
juk, miként lehet az STL haladóbb konstrukcióit kihasználva kidolgozni néhány 
funkciót. Mindkét változat teljes forráskódja megtalálható a CD-mellékleten. 


14.1. Alapfunkciók 


14.1.1. A feladat áttekintése 





Feladat: Egy kereskedés számítógép-alkatrészek és számítógép-konfigurációk értékesítésével 
foglalkozik. Elsődleges feladatunk egy olyan alkalmazás elkészítése, amely lehetőséget biztosít 
a kereskedés alkatrészeinek és konfigurációinak nyilvántartására. Ennek keretében támogatnia 
kell a termékek állományból való betöltését, képernyőre történő listázását, állományba való 
kiírását és az árképzés rugalmas kialakítását. 


Mivel számítógép-kereskedésünk várakozáson felül teljesít, gondolataink már 
a jövőbeli befektetések körül járnak. Így a távolabbi jövőben teljesen új ter- 
mékcsaládok értékesítésének bevezetése sem kizárt. Ezért nyilvántartó rend- 
szerünket úgy kell kialakítani, hogy a lehető legegyszerűbb legyen a jövőben 
az új termékcsaládok támogatása. Ezt egy kétkomponensű megoldás kialakí- 
tásával érhetjük el. Egyrészt osztálykönyvtár (class library) formájában meg- 
valósítunk egy keretrendszert, amely általános módon támogatja a termék- 
családok kezelését, másrészt ennek felhasználásával elkészítjük a számító- 
gép-alkatrészeket kezelő futtatható alkalmazást. Célunk az, hogy a jövőben a 
keretrendszerre építve, annak megváltoztatása nélkül, minél kevesebb 3Eei 
kával készíthessünk olyan alkalmazásokat, amelyek más termékcsaládokai 
(például építőanyagok) is támogatnak. B 

A Tvelkezékben fidetésen összefoglaljuk a keretrendszerrel és at BENI 
épülő alkalmazással szemben megfogalmazott követelményeket. A keretre: 
Szerre vonatkozó követelmények a következők: 
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e A keretrendszert úgy lehessen felhasználni, hogy ne kelljen kiadni a 
forráskódját. 

s — A keretrendszernek támogatnia kell az egyes termékek adatfolyamból 
való betöltését, adatfolyamba való kiírását és adatfolyamba (jellemzően 
képernyőre) történő formázott (jól olvasható) kiírását. 


e — A termékek fontosabb attribútumai a következők: beszerzési ár, beszer- 
zés dátuma, név és típus. Az aktuális ár a termék attribútumainak 
függvényében számítandó, a számítás módja függhet a terméktípustól, 


. — Egy termék lehet elemi vagy összetett. Ez utóbbiak több termékből 
épülnek fel (ilyen például a számítógép-konfiguráció), amelyek szintén 
lehetnek elemiek vagy akár összetettek. 


Az alkalmazásra vonatkozó követelmények: 


, A támogatott termékek a következők (zárójelben az attribútumokkal): 
kijelző (szélesség és magasság hüvelykben), merevlemezes egység (se- 
besség RPM-ben), számítógép-konfiguráció. Az utóbbi összetett termék. 


A keretrendszer osztályait egy ProductlnventoryLib nevű Ct- osztálykönyv- 
tárban (library, .lib) valósítjuk meg. Így a felhasználásához csak a lefordított 
könyvtárra és az osztálydefiníciókat tartalmazó fejlécfájlokra van szükség (a 
tagfüggvények definícióit tartalmazó forrásfájlokra nincs). 

A keretrendszerre épülő alkalmazást nem fogjuk teljesen elkészíteni. El- 
készítünk ellenben egy ProductinventoryTest nevű tesztalkalmazást, amely- 
ben bevezetjük a számítógép-kereskedésre jellemző termékeket, és írunk 
tesztelést szolgáló kódot. 


14.1.2. A termékek reprezentálása 


A termékek reprezentálására szolgáló osztályok kapcsolatát a 47. ábrán lát- 
ható UML osztálydiagram szemlélteti. 

Az ábrán szereplő osztályokkal fokozatosan fogunk megismerkedni. A ter- 
mékek reprezentálására a keretrendszerben bevezetjük a Product osztályt, 
amely lehetővé teszi valamennyi termék egységes kezelését, valamint ebbe az 
osztályba tehetjük az összes termékre vonatkozó közös kódot. A keretrend- 
szer felhasználásakor az elsődleges feladat a Product osztályból történő le- 
származtatással az egyes specifikus termékeket reprezentáló osztályok (pél- 
dául HardDisk, Display) definiálása. 
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ProductinventoryLib (keretrendszer) 








ComposíteProduct 
AI 


jj 
li 
véres HardDisk EEEs 




















ProductinventoryTest (alkalmazás) 


47. ábra. A termékosztályok és kapcsolataik 


A Product osztály szolgáltatásait az osztály forráskódja alapján fogjuk átte- 
kinteni. 


// File: product.h 
$ifndef PRODUCT H 
$define PRODUCT H 


finclude ciostreams 
finclude cctimes 


class Product 


protected: 

int initialPrice; // Beszerzési ár 

time t dateofAcguisition; // Beszerzés dátuma 

std::String name; // Név 

Virtual void printParams(std::ostreamé, 05) const; 

Virtual void loadparamsFromStream(std::istreamé is); 

Virtual void writeParamsToStream(std::ostream§ 05) const; 
public: 

Product() ; 

Product(std::sString name, int initialPrice, time.t 

, dateofAcgui sition); 

Virtual cProductO) (3; 

int GetinitialPriceO const; 

Std::string GetName() const; 

time t GetDateofacguisition() const; 

int GetageO) const; 

virtual int GetcurrentPrice() const; 

void Print(std::ostreamg os) const; 

Virtual std::sString GetType() const - 0; 

Virtual char Getcharcode() const - 0; 
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A tagfüggvények definícióit fokozatosan tekintjük át. A Product osztály az 
initialPrice (beszerzési ár, int), dateOfAcguisítion (beszerzés dátuma, time t) 
és name (név, std::string) tagváltozókkal rendelkezik. Ezek védett, protected 
tagváltozók, a , külvilág" számára csak olvasható módon férhetők hozzá, a Get. 
InitialPrice, GetDateOfAcguisition és GetName publikus tagfüggvényekkel: 





A GetAge tagfüggvény az aktuális dátum és a beszerzési dátum alapján a 
termék korát adja vissza napokban: 





A Product osztály lehetőséget biztosít az aktuális ár kiszámítására is (Get- 
CurrentPrice művelet), ami azonban már termékfüggő. Ennek megfelelően a 
Product osztályban virtuálisnak definiáljuk, a leszármazott osztályok feladata 
ennek felüldefiniálásával a termékspecifikus árszámítás elvégzése. A Product 
osztályban a GetCurrentPrice a kiindulási árat adja vissza, így a leszármazot- 
tak esetében ez lesz az alapértelmezett működés: 
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Következzen egy példa a GetCurrentPrice felüldefini é 
ál, siltébe; efiniálására a HardDisk osz. 





Minden terméktípushoz, vagyis minden Product-leszármazotthoz tartozik egy 
sztring típusnév, valamint egy egyetlen karakterből álló típuskód (ez utóbbi 
szerepére még visszatérünk). Ezek lekérdezésére a Product osztályban a Get- 
Type és a GetCharCode tagfüggvények szolgálnak. Mivel mindkettőnek csak az 
egyes leszármazott osztályokban tudunk implementációt adni, a Product osz- 
tályhoz tartozó fejlécfájlban absztrakt virtuális függvényeknek definiáltuk őket: 






Az alábbi kódrészlet példa arra, hogyan kell ezt a két függvényt felüldefiniál- 
ni egy specifikus termékosztály esetében (HardDisk): 





A követelmények között szerepelt, hogy szükség van a termékek formázott 
megjelenítésére. Ezt a szolgáltatást egy adott termékre vonatkozóan a sáket 
Ssztály Print tagfüggvénye nyújtja. A Print függvénnyel szemben az elvárá- 
sunk az, hogy minden termék esetében írja ki a termék típusát, nevét, az égi 
Szes termékre közös paramétereket (beszerzési ár, beszerzés dátuma, 116 h8 - 
(ális ár) és az adott termék típusától függő paramétereket (például Display 
ésetén a méretek). A kimenetre példa a következő: 
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Type: Display, Name: TFT1, InitialPrice: 30000, DateofAcguisíition: 
20011001, Age: 2092, current price: 30000, Inchwidth: 12, 
InchHeight: 13 


A Product::Print függvény egyrészt kiírja a nevet és a típust, majd a további 
paraméterek megjelenítésére a printParams tagfüggvényt hívja. Mivel a név 
és a típus megjelenítésére minden esetben szükség van, a Print tagfüggvény 
nem virtuális (nem tervezzük ennek felüldefiniálását): 





A paraméterek kiírása viszont típusfüggő, így a printParams függvény virtuá- 
lis. A Product osztályban ez a beszerzési ár, a beszerzés dátuma, a kor és az 
aktuális ár termékparamétereket írja ki: 





Ha egy leszármazottban (például Display osztály) felüldefiniáljuk a Product 
osztály printParams tagfüggvényét, és elvárásunk az, hogy ezen paraméterek 
is jelenjenek meg, akkor a termékspecifikus paraméterek kiírása előtt hívjuk 
meg a Product ősosztály printParams tagfüggvényét:121 








"" Megoldásunkban lehetővé tesszük, hogy a Product leszármazottjai a Product::printParams 
hívásával igény szerint kiírják az általános termékparamétereket, vagy eltekintsenek et- 
től. Ha ezeket minden termék esetén egységesen ki szeretnénk íratni, akkor a Pro- 
duct:printParams tartalmát emeljük át a Product::Print függvénybe a printParams(os): 
sor elé, a Product::printParams törzse pedig legyen üres. 
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A legösszetettebb feladat a termékek adatfolyamból (például állományból) való 
beolvasásának és adatfolyamba való kiírásának megvalósítása. A kerekek 
adatfolyamban való tárolására a következő reprezentációt választottuk (példa): 


d TFT1 30000 20011002 12 13 
d TFT2 35000 20061001 10 10 
h Maxtor 25000 20050301 7000 


Minden sor egy termék adatait tartalmazza és minden sor elején egy karak- 
terből álló típuskód (terméktípus azonosító) áll. A "d? esetünkben a Display tí- 
pusú, a h a HardDisk típusú termékeket jelöli. Ezt követően a minden ter- 
mékre közös mezők a következők: név (például TFT1), beszerzési ár (pl. 
30000), a beszerzés dátuma (pl. 20011002) és a termékfüggő paraméterek 
(például 12 és 13 a kijelző szélessége és magassága). 

Egy termék adatfolyamba írására a Product osztály writeParamsTo- 
Stream tagfüggvénye szolgál. Ez gondoskodik a minden termékre közös pa- 
raméterek (név, kezdeti ár, beszerzés dátuma) adatfolyamba írásáról: 





Az aktuális árat értelemszerűen nem tároljuk el, hiszen az egy — esetlegesen 
az aktuális dátumtól is függő — számított érték. A writeParamsToStream tag- 
függvény természetesen virtuális, a leszármazott osztályokban definiáljuk 
felül, és az ősbeli writeParamsToStream hívását követően gondoskodjunk a 
termékspecifikus paraméterek kiírásáról: 
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A termékek adatfolyamból történő beolvasása a kiírásnál jóval összetettebb 
feladat, alapvetően két részre bontható. 

Egyrészt szükség van egy feldolgozó osztályra, amelyik soronként haladva 
beolvassa az első karaktert (a termék típuskódját), ennek függvényében dina. 
mikusan létrehoz egy megfelelő termékobjektumot (például "d" kód esetén egy 
Display, "h" kód esetén egy HardDisk osztálybeli objektumot). Az erre vonatkozó 
megoldás részleteire rövidesen visszatérünk. Ezt követően a termékparaméte. 
rek beolvasása, vagyis az állománysor megmaradó részének feldolgozása a már 
létrehozott Product leszármazott osztálybeli objektum feladata. Ez nem is lehet 
másként, hiszen a paraméterek értelmezése termékspecifikus, csak a Product 
leszármazott osztályok tudják, hogyan kell értelmezni az állományban levő ter- 
mékspecifikus adatokat. A beolvasás elve a kiíráséhoz hasonló: a Product osz- 
tálybeli loudParamsFromStream virtuális függvény feladata a minden termék- 
re közös adatok beolvasása (név, beszerzési ár, beszerzés dátuma), a leszárma- 
zott osztályoké pedig a maradó termékspecifikus adatok értelmezése: 











Zárógondolatként megemlítjük, hogy a termékek 
írását és onnan történő olvasását támogatja a 
megfelelő túlterhelt változatának megírása: 


kényelmes adatfolyamba 
globális cc és ss operátorok 





Mivel ezen operátorok nem termékspecifikusak, csak egy helyen, a keret- 
rendszerben kellett őket megírni. 


14.1.3. Összetett termékek 


Keretrendszerünket úgy kívánjuk megírni, hogy támogassa tetszőleges össze- 
tett termék bevezetését. Ennek egy specifikus esete például a számítógép-konfi- 
guráció. Az összetett termékek reprezentálására a CompositeProduct osztályt 
vezetjük be. Mivel az összetett termék is termék, és a többi termékkel egysége- 
sen kívánjuk kezelni (például közös listában kívánjuk tárolni), a Composite- 
Product osztályt a Product osztályból származtatjuk. Az összetett termékek egy 
std::vectorcProduct"2 parts; tagváltozóban, vagyis a tartalmazott termékekre 
mutató pointerek listájának formájában tárolják a tartalmazott termékeket. 
Egy termék listába történő felvételét az AddPart(Product" product) tagfügg- 
vény teszi lehetővé. CompositeProduct osztályunk forráskódja a következő: 
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$include "product.h" 


class CompositeProduct : 
§ public Product 
Std::vectorcProduct"5 parts; 
protected: 
void printParams(std::ostreamé os) const; 
void loadPparamsFromStream(std::istreamé is); 
void writeParamsToStream(std: :ostream$ os) const; 
public: 
CompositeProduct() ; 
-CompositeProduct() ; 
void AddPart(Product" product); 
3; 
ftendif /: COMPOSITEPRODUCT H §/ 


// File: CompositeProduct.cpp 
finclude "CompositeProduct.h" 
$include "ProductFactory.h" 


using namespace std; 


CompositepProduct: : CompositeProduct() : 
Product() í b 


Hete CcompositepProduct : : AddPart(Product" product) 
parts.push back(product); 


Megoldásunkban a CompositeProduct objektumok feladata a tartalmazott 
(dinamikusan létrehozott) termékobjektumok felszabadítása: 


Slsjáti teproduct: :-CompositeProduct() 
for(unsigned 1-0; i c parts. zeO;i44) 6. 


delete parts[(i)]; 
parts.clearO; 





A formázott kiíráshoz felüldefiniáljuk a Product ősosztályból örökölt print- 
Params virtuális függvényt: először a Product::printParams() hívásával ki- 
íratjuk az összetett termékre mint egészre vonatkozó adatokat, majd kiírat- 
juk valamennyi tartalmazott termék paraméterét: 
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Az alábbiakban nézzünk meg egy példát a kimenetre egy ComputerConfiguration 
objektum (CompositeProduct leszármazott) esetére: 


Type: Computerconfiguration, Name: Computerconfig, Initialprice: 
35000, DateofAcguisition: 20060930, Age: 267, Current price: 60000 
Items: 

0. :Type: Display, Name: TFT3, InitialPrice: 30000, 
pateofaAcguisition: 20011001, Age: 2092, current price: 30000, 
Inchwidth: 12, InchHeight: 13 

1. :Type: HardDisk, Name: WesternDigítal, InitialPrice: 35000, 
DateofaAcguisiítion: 20060930, Age: 267, Current price: 28000, 
SpeedRPM: 7000 


Eddig ugyan nem említettük, de azáltal, hogy a CompositeProduct a Product 
osztályból származik, és így örökli annak initialPrice, dateOfAcguisition és 
name tagváltozóit, az összetett termékek a tartalmazott termékektől függetle- 
nül egyedi kiindulási árral, beszerzési dátummal és névvel rendelkezhetnek. 

Összetett termékek adatfolyamba való kiírása során az alábbi reprezen- 
táció mellett döntöttünk (példa): 


d TFT1 30000 20011002 12 13 

d TFT2 35000 20061001 10 10 

c Computerconfigl 70000 20061001 2 

d TFT3 30000 20011002 12 13 

h westernDigital 35000 20061001 7000 
h Maxtor 25000 20050301 7000 


A példánkban a 3., a 4. és az 5. sor egy összetett terméket, számítógép-konfi- 
gurációt reprezentál. A harmadik sorban a C termékkód a ComputerConfigu- 
ration terméktípusra utal, ezt követik a termékparaméterek (név, JRSZÉKESSS 
ár, beszerzés dátuma), majd a sor végén utolsó paraméterként S KÁGTS AS] 
termékek száma. Ezt beolvasva tudjuk meg, hogy a következő sorok teki 
hány tartozik az összetett termékhez. Ez esetünkben a követkeső két s. Mát 
lenti, vagyis a konfigurációhoz egy TFT3 nevű Display és egy Western. úg 
nevű HardDisk tartozik. Az adatok kiírása a writeParamsToStream tagtügs: 
vényben e reprezentációnak megfelelően történik: 
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Az összetett termékek beolvasásához felüldefiniáltuk a loadParamsFrom- 
Stiream tagfüggvényt, aminek működése egy sor kivételével a reprezentáció 
ismeretében könnyen megérthető. 





A kiemelt kódrész felelős a sorok elején található termékkód beolvasásáért és 
az ennek megfelelő Product leszármazott termékobjektum létrehozásáért, a 
megoldás részleteinek ismertetésére rövidesen visszatérünk. 


14.1.4. Termékek nyilvántartása 


Jelen pillanatban keretrendszerünk osztályai egyszerű és összetett termékek 
reprezentálását támogatják, de még nincs olyan osztályunk, amely elvégezné 
a termékek nyilvántartását. E célból vezessük be a Productlnuventory osztályt, 
melynek feladatai a következők: termékek listájának betöltése adatfolyamból, 
a betöltött termékek tárolása a memóriában, a memóriában tárolt termékek 
adatfolyamba írása, valamint a termékek formázott megjelenítése. Mint az 
alábbi UML osztálydiagramon is látható, a Productinuventory osztályt a keret- 
rendszerben definiáltuk, és valamennyi nyilvántartott termékre egységes 


módon, Productként (pontosabban, mint látni fogjuk, Product mutatóként) 
hivatkozik. 
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48. ábra. A Productinventory és a Product osztály kapcsolata 


Az osztálydefiníciót tartalmazó fejlécfájl a következő: 





Az osztály felépítése nagyon hasonlít a korábban tárgyalt faaposikéráe s 
osztályéhoz. A termékek tárolása ez esetben egy products nevű, Hzsékol] v4wa 
ductt típusú tagváltozóban történik. A következőkben tagfüggvények definí 
cióit tekintjük át. 





Az osztályunk felelős a tárolt objektumok felszabadításáért: 
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A PrintProducts tagfüggvény támogatja a tárolt termékek formázott listázását: 





Egy példa a megjelenítésre: 


0.: Type: Display, Name: TFT1l, InitialPrice: 30000, 
Dateofacguisition: 20011001, Age: 2092, Current price: 30000, 
Inchwidth: 12, InchHeight: 13 
1.: Type: Display, Name: TFT2, InitialPrice: 35000, 
DateofAcguisition: 20060930, Age: 267, Current price: 35000, 
Inchwidth: 10, InchHeight: 10 
2.: Type: Computerconfiguration, Name: ComputerConfigl, 
InitialPrice: 70000, DateofAcguisition: 20060930, Age: 267, Current 
price: 70000 
Items: 
0. :Type: Display, Name: TFT3, InitialPrice: 30000, 
DateofAcguisition: 20011001, Age: 2092, Current price: 30000, 
Inchwidth: 12, InchHeight: 13 
1. :Type: HardDisk, Name: WesternDigital, InitialPrice: 35000, 
DateofAcguisition: 20060930, Age: 267, Current price: 28000, 
SpeedRPM: 7000 
3.: Type: Hardpisk, Name: Maxtor, InitialPrice: 25000, 
DateofAcguisition: 20050228, Age: 846, Current price: 20000, 
SpeedRPM: 7000 


A Readlnventory tagfüggvény felelős az alábbi (korábban már tárgyalt) formá- 
tumban tárolt termékek adatfolyamból történő beolvasásáért, a Writelnventory 
tagfüggvény pedig ennek megfelelő formátumban írja ki a tárolt termékeket: 


d TFT1 30000 20011002 12 13 

d TFT2 35000 20061001 10 10 

c Computerconfigl 70000 20061001 2 

d TFT3 30000 20011002 12 13 

h westernDigital 35000 20061001 7000 
h Maxtor 25000 20050301 7000 








Az AddProduct a paraméterben megkapott terméket veszi fel a terméklistára, 
de előzetesen validálja a paramétert: ha értéke NULL, invalid argument ki- 
vétel dobásával jelzi a hibát a hívó számára. 





14.1.5. Termékobjektumok létrehozása 


A termék, vagyis a különböző Product leszármazott osztálybeli dbisatumáke 
kat CompositeProduct és ProductInventoy osztályainkban az adatfolyamból 
való beolvasás során a következő módon hozzuk létre: 





aljuk össze, mi ennek a kód- 
Ivasása az adatfolyam adott 
gfelelő Product leszármazott 0sz- 
amétereinek beolvasása mar 
lő funkcionalitást várunk: 


Mielőtt rátérnénk a részletes magyarázatra, fogl 
részletnek a feladata: egyrészt a termékkód beo 
sorának elejéről, majd a termékkódnak mei 
tálybeli objektum létrehozása (a termék par: 
nem), Vagyis a következő kódrészletnek megfele! 
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Ám, ha jobban belegondolunk, ez a megoldás így önmagában nem alkalmazha- 
tó, Ennek a kódrészletnek ugyanis a CompositeProduct és a ProductInventoy 
osztályok tagfüggvényeiben kellene szerepelnie, ezek az osztályok viszont a 
keretrendszerünkben (vagyis a ProductilnventoryLib könyvtárban) definiál- 
tak, amely csak az általános Product osztályt ,ismeri", a leszármazottait 
(Display, HardDisk) nem. A gondot az objektumokat a new operátorral dina- 
mikusan létrehozó sorok jelentik, a keretrendszer osztályainak kódjában a 
Display, HardDisk stb. osztálynevek nem szerepelhetnek. Szintén probléma, 
hogy minden egyes új termék bevezetésekor fel kellene vennünk egy új case 
ágat, vagyis módosítani kellene a keretrendszert, és újra kellene fordítani a 
ProductlnventoryLib könyvtárat. Ez ellentmond a korábban megfogalmazott 
követelményeinknek. 

Felmerül a kérdés, milyen megoldás biztosíthatja a keretrendszerünk ál- 
talánosságát, vagyis hogyan tudjuk keretrendszer-osztályainkban úgy létre- 
hozni az egyes specifikus termékeket, hogy nevüket nem szerepeltetjük a ke- 
retrendszer osztályaink kódjában. A megoldást az indirekció és a virtuális 
függvények megfelelő alkalmazása jelenti: a termékkód beolvasását és a meg- 
felelő termékobjektum létrehozását egy újonnan bevezetett ProductFactory 
osztálybeli objektumra, pontosabban annak ReadAndCreateProduct tagfügg- 
vényére bízzuk. A ProductFactory osztályát és annak ReadAndCreateProduct 
tagfüggvényét a keretrendszerünkben definiáljuk (hogy már a keretrendszer 
osztályaiból is használható legyen), ugyanakkor a ReadAndCreateProduct a 
termékkódnak megfelelő termékosztály példányosítását egy CreateProduct 
nevű absztrakt (tisztán virtuális) metódusra bízza: 








14.1. Alapfunkciók 










7 Ha nincs semmi hiba és fájlvége jezteiá, 
!1is.g00dO) 5 


if Cis.eofO) return NULL; ENNYI 






cout cc "There was an error reading the product ems!" 
az endi; : a 
return NULL; 


j 


—— Productt product - CreateProduct( typeCode ); 
/ — if (product —— NULL) // Ha p NULL 
gli 





cout cc "Unknown product type." cc endi; 


return product; 


5 ú 


A CreateProduct tagfüggvény feladata a paraméterben megkapott termék- 
kódnak megfelelő termékosztály példányosítása, és az újonnan létrehozott ob- 
jektumra mutató pointerrel való visszatérés. A CreateProduct-nak a keret- 
rendszerben absztraktnak kell lennie, hiszen korábbi gondolatmenetünknek 
megfelelően a termékeket példányosító switch-case szerkezetet nem tehetjük 
be a keretrendszerbe. Ugyanakkor betehetjük a kertrendszerre épülő alkal- 
mazásba, amely a specifikus termékeket (például Display, HardDisk) is defi- 
niálja. Már csak egy lépésre vagyunk a megoldástól: az alkalmazásunkban be 
kell vezetnünk egy ProductFactory leszármazott osztályt, felül kell definiál- 
nunk a CreateProduct tagfüggvényt, és ebben kell elhelyeznünk a termékeket 
példányosító switch-case szerkezetet. Számítógép-kereskedésünk esetében 
nevezzük ezt az osztályt ComputerProductFactorynak. Amikor a keretrend- 
szerünk  ProductFactory::ReadAndCreateProduct  tagfüggvénye meghívja § 
CreateProduct virtuális függvényt (vastagon kiemelt sor a fenti kódrészlet- 
ben), akkor a ComputerProductFactory objektumok esetében a leszármazott 
ösztálybeli CreateProduct hívódik meg, amely létrehozza a megfelelő terméket. 
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Ezzel a termékek példányosításának mechanizmusát nagyrészt ismertettük, 
az osztályok kapcsolatáról az alábbi UML ábra ad áttekintést: 





ProductinventoryLib (keretrendszer) 














49. ábra. A termékek létrehozásáért felelős osztályok kapcsolata 





14.1. Alapfunkciók 


Egy pillantást vetve a ProductFactory osztály használatá; iteProd: 
és a ProductInventoy osztályainkban, az alábbiakban Kinél kélveei t Get. 
Instance) még mindig magyarázatra szorul: elegge 





Sejthetjük, hogy a Getlnstance a ProductFactory osztályunk egy statikus tag- 
függvénye, de miről is van szó? ProductFactory osztályból (pontosabban an- 


nak alkalmazáspecifikus leszármazottjából) mindössze egy példányra van 
szükség, ehhez az egy példányhoz azonban több helyről is szeretnénk hozzá- 
férni (A CompositeProduct és a ProductInventory osztályokból). A problémára 
megoldást jelenthetne a keretrendszerben definiált globális változó definiálása 


[7 ProductFactory? theProductFactory - NULL; MEZ ze eves 


és az alkalmazásban történő inicializálása: 











rn ProductFactory? theProductFactory; ) -sgkg 
ictFactory - new computerProductFactoryO; 





A globális változókat azonban objektumorientált környezetben nem szeretjük 
használni, mivel nagyobb a névütközés veszélye. Milyen alternatív megoldás 
létezik? Globális változónkat egy statikus tagváltozó formájában , ágyazzuk 
be" a ProductFactory osztályba instance néven, egy Getlnstance nevű statikus 
tagfüggvénnyel biztosítsunk ehhez hozzáférést, és egy Init nevű statikus tag- 
függvénnyel tegyük lehetővé az inicializálását. 


ProductFactory.h Nt 
ciostreams 88 
: "Product.h" 
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void ProductFactory::Init(ProductFactory" pf) 


( 
instance - pf; 
) 
ProductFactoryt ProductFactory: :GetInstance() 
( 
return instance; 
J 
Az alkalmazásunkban inicializáljuk a ProductFactoryt, mielőtt keretrendsze- 
rünket használnánk: 


ProductFactory: : Init(new ComputerProductFactory()); 


14.1.6. Tesztelés 


alábbi kódr 
t szolgálja, valamint példát mutat a Productlnwentory osz 





tályainak teszte- 
ály használatára: 


nk os 





let a keretrendszerünk és alkalm: 








// File: ProductInventoryTest.cpp 


tinclude cfstreamz 
finclude " , , /ProductInventoryLib/ProductInventory.h" 









finclude . /ProductInventoryLib/ProductFactory.h" 
finclude "ComputerProductFactory.h" 
tinclude "oisplay.h" 





ftinclude "Hardpisk.h" 
using namespace std; 


void ReadinvFromFilerTest(ProductInventoryé inv); 
void WriteInvToFilerest(ProductInventoryá inv); 


int mainCint argc, char" argv[]) 
( 
try 
( 
ProductFactory: :Init(new ComputerProductFactory()) ; 


// Tesztl: készlet létrehozása és kiírása a kimenetre. 
cout cc "Testl: creating inventory and printing " 
"it to the screen." cc endi; 
time t currentTime; 
time(gcurrentTime) ; 
ProductiInventory invl; 
MAT alötroduebe new Display("TFTI", 30000, currentTime, 
, 12) ); 
záros se LAN new Hardoisk("wD", 25000, currentrime, 
inv1.PrintProducts( cout ); 
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14.1. Alapfunkciók 


//Vvárunk billentyű leütésre 

cout cc "Press any key to continue..." 
cin.getO; § 
cout cc endi; 


cout cc "Test2: loading inventory from a file" 
" (computerproducts.txt), printint it, and then writing " 
"it to a file (computerproducts. out. txt) ." cc endl; 
Productinventory inv2; x 
ReadinvFromFilerest(inv2) ; 
writeInvToFilerest(inv2) ; 
cout cc endi; 
cout cc "Done."; 
//Várunk billentyű Teütésre 
cin.get(); 


return 0; 

! 3 

catch(const std::exceptiong e) 

( 
cerr cc "There was an error: " ce endi; 
cerr cg e.what() cc endi; 


catch(...) 
í 
cout cc "Uunexpected error occured." cc endi; 
, 
h 


// Termékek betöltése a "../TestData/computerproducts.txt" 
// állományból és Tistázásuk a szabványos kimenetre. 
void ReadInvFromFilerest(ProductInventory$ inv) 


al 
ifstream fs("../TestData/computerproducts.txt"); 
if (Ifs) 
t 
cerr cc "Error opening file." cc endi; 
return; 
J 


inv.Readinventory(fs); dara s/ 
cout cc "The content of computerproducts.txt is: cc endi; 
inv.PrintProducts (cout) ; 

cout cc endi; 


, 

// Termékek kiírása a "../TestData/computerproducts. out . txt" 
// állományba. 5; 

void writelnvroFilerest(ProductInventoryé inv) 

1 


ofstream fs(".. /rTestpata/computerproducts. out.txt pH 
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14. fejezet: Esettanulmány 





14.2. További funkciók az STL használatával 


Elsőként vizsgáljuk meg a ComposíteProduct osztályt! A parts tagváltozó Pro- 
duct típusú pointereket tárol, A pointerek felszabadítását leegyszerűsíthetjük 
a 12.1.3. Algoritmusok fejezet Rendezett vektor részében tárgyalt delete ptr 
sablonnal: 





Rendezzük sorba a CompositeProduct által tartalmazott termékeket a termé- 
kek neve szerint! Az ábécérend megállapításához használjuk az éppen beállí- 
tott globális nyelvi környezetet! 

Elsőként a Product £ operátorát kell megírnunk, amely a nyelvi környe- 
zet zárójel operátorát használja a sorba rendezéshez (12.6.2. A nyelvi környe- 
zetek programozása fejezet Magyar nyelvű szövegfeldolgozás rész): 





A megvalósításhoz felhasználtuk a 12.1.3. Algoritmusok fejezet Rendezett vek- 
tor részében ismertetett compare ptr by value függvényobjektumot, amely a 
pointereket a mutatott érték - operátora szerint hasonlítja össze. 





14.2. További funkciók az STL használatával 

Megjegyezzük még, hogy a dátum kiírását és beolvasását, ille 

végzett műveletek megvalósítását elegánsabb lenne egy dátúmosz 

végezni. A dátum kiírását hasonlóan az idő kiíratásához (12.6. A 

nyezetek programozása fejezet A nyelvi környezetek és az ada, 

csolata rész) a nyelvi környezet time get és time put arculatai 
elegánsan: 


tve a rajta 
tályban el- 
2. A nyelvi kör. 
tfolyamok kap- 
val végezhetjük 


class Date 


tí 
std::tm time; 


template cclass charT, class Traitss 

friend std::basic istreamccharT, Traitssé operator ss 
(Cstd::basic istreamccharT, Traitss€, Dateg) ; 

template cclass charT, class Traitss 

friend std::basic. ostreamccharT, Traitssé operator cc 
(Cstd::basic ostreamccharT, Traitss€, const Date 89; 


public: 
// Inicializálás az aktuális helyi dátummal 
DateO 
18 
memset(€time,0, sizeof(std::tm)); 
timelt now z- std::time(NULL); 
time - "Ilocaltime(ánow); 


Date(const std::tm € time) :time(timel(); 
Date(time t t) 
a 
time-"1ocaltime(€t) ; 
j 


int GetElapsedpays() const 
( 
time t currentTime; 
Std::time(gcurrentTime) ; 


double timepiffiInsec - difftime(currentTime, 
41. mktime(const. castctmt (€time))) ; 


return (int) (timepiffInsec/(3600"24) ) ; 
36 


Az egyes termékek korának lekérdezéséhez a GetElapsedDays függvi 6éyő 288 
implementáltuk. A függvény érdemben nem változtatja az objektum állapo- 
tát, mert a mktime csak normalizálja az átadott struktúrát, a dátunot hada 
változtatja meg. E nyugodt szívvel használjuk a const. cast operátort, és a 


függvényt konstansnak deklaráljuk. A kiírást az alábbi sablonoperátor végzt: 
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14. fejezet: Esettanulmány 





template cclass charT, class Traitsz 
std::basic ostreamccharT, Traitsz6 operator cc 
Cstd::basic ostreamccharT, Traits2€ os, const Date § t) 


t 


std::basic ostreamccharT, Traitsz::Sentry sntr(os); 
if(C!sntr) return os; 


char "pattern - "XY/Xm/9d" ; 


std::use facetcstd: : tíme putccharT, 
ostreambuf. iteratorccharT,Traitszz 2 
(os .getloc()) .put(os,os,os.fillO ,ét.time,pattern, 
pattern 4 strlen(pattern)); 
os .width(0) ; 
return os; 


Hi 


A példában a dátumot a megadott minta szerint írjuk ki. A beolvasást a time get 


arculat get date tagfüggvényével végezzük 


template cclass charT, class Traitsz 
std::basic ístreamccharT, Traits2€ operator 22 
(Cstd::basic istreamccharT, Traitsz€ is, Date § t) 


( 


std::basic istreamccharT, Traitsz::Sentry sntr(is); 
if(!sntr) return is; 





std::ios base::jostate state z 0; 
std::tm temp; 

memset(§temp,0, sizeof(std::tm)); 
temp.tm isdst s -1; 


std::use facetcstd::tíme getccharrT, 
std::istreambuf, iteratorccharT,Traiítsz 5 5 
(is.getloc()) .get dateCis, 
std::istreambuf iteratorccharT,Traitso(), is, state, €temp); 


if(state § ios::failbit) 
í 
is.setstate(ios::failbit); 
) 
else 
( 
t.timestemp; 
) 


ís .width(0); 
return is; 





14.2. További funkciók az STL használatával 


A fenti megoldásban csak az jelenthet problémát 
nem egyezik meg a kiírás formátumával, Ekkor szdödté tele E kvk. 
tumsztringjét az adott beállításhoz tartozó, get date által várt formáti hé. 
A Szabványos Ct- Könyvtár sajnos nem tartalmaz dátumosztál, j ek 
fenti, mélyebb ismereteket igénylő kódrészlet megírását szlkéértáleeáé ta it 7 
ilyen alapfunkció esetén. Szerencsére, mint ahogy a 12.6.2. A nyelvi körn. tek 
programozása fejezet A nyelvi környezetek és az adatfolyamok köpésoláztég zé- 
ben utaltunk rá, számos szabadon letölthető ingyenes megoldás áll rendelkezé 
sünkre, amelyek a fenti, csak az esettanulmányhoz szükséges funkciókat m 4 
valósító Date osztályánál jóval több szolgáltatást nyújtanak. Ugyanakkor a je 
dátumosztály kiegészítése egyáltalán nem nehéz programozási feladat. 
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TIZENÖTÖDIK FEJEZET 
Utószó 


Reméljük, hogy munkánk nem volt hiábavaló, és a Kedves Olvasóban meg- 
érett egyfajta szemlélet, amelyet az objektumorientáltság és a C-t logikája 
alakított ki. Bízunk benne, hogy ez a szemlélet könnyebbé és CrSLNÁNYESÜLBE 
teszi a mindennapok fejlesztői munkáját, és könyvünk továbbra is segítséget 
nyújthat egy-egy megoldandó feladathoz. 

Mivel a CH számos modern objektumorientált programozási nyelv őse, 
remélhetőleg azok is hasznosnak találják, hogy megismerkedtek ezzel a sokszor 
igen összetett nyelvvel, akik újabb programozási nyelvekkel fognak találkozni. 

A továbbfejlődéshez természetesen elsősorban azt tanácsoljuk, hogy írjon 
az Olvasó minél több C-- nyelvű programot, emellett javasoljuk a szakiroda- 
lom tanulmányozását is: 

Számos könyv ad tanácsokat, megoldásokat bizonyos konkrét problémákra. 
Ezek a könyvek nem ismertetik a Ct- alapjait, általában problémamegoldás 
szerkezetben tárgyalják a haladó ismereteket. Ilyenek az [7, 8, 10] irodalmak. 

Az objektumorientáltság témakörében számos kiváló, az objektumorientált 
tervezést bemutató könyv létezik, ezek közül különösen kiemelkedő a [15], 
amely Ct- kóddal illusztrálja az ismertetett tervezési megoldásokat. Mivel ez a 
könyv az UML szabvány előtt keletkezett, az osztálydiagramon a szerepnevek 
az UML-ben meghatározotthoz képest fel vannak cserélve az asszociációk vége- 
in. Az UML részletesebb megismeréséhez a [17] irodalmat ajánljuk. 

Az STL témakörében a [9] könyvet ajánljuk, amely egyben referencia- 
könyv is. Az Apache szabványos könyvtárának dokumentációjához tartozik 
egy interneten elérhető kézikönyv (http:/incubator.apache.org/stdexx/doc/ 
stdlibug/index.htm]), amely szintén igen alaposan körüljárja a szabványos 
könyvtár lehetőségeit. 

Végezetül szeretnénk megköszönni az Olvasó kitartását és türelmét, és 
sok sikert kívánni a Ct- nyelvű fejlesztéshez. 

















A FÜGGELÉK 


A C44 operátorok 
precedenciatáblázata 


A C44 örökölte a C nyelv operátorait, és néhány új operátorral megtoldotta 
őket. Az alábbi táblázat a C-t összes operátorát tartalmazza, a C-- által be- 
vezetetteket vastag betűvel szedtük. A táblázat egyes sorai az azonos prece- 
denciaszintű operátorokat foglalják magukba, a második oszlop az operátorok 
asszociativitását mutatja. Minél előrébb van egy operátor a táblázatban, 


annál 
nagyobb a precedenciája. 





:: (hatókör) nincs 





(tagkiválasztás); — (tagkiválasztás pointer); [] (index); —— balról jobbra 
O(függvényhívás); O(taginicializálás); 

tt (postfix növelő); — — (postfix csökkentő); 

typeid( ) (típusnév); 

const cast; dynamic cast; reinterpret cast; 

static cast (C-t típuskonverziós operátorok) 








sizeof (méret); jobbról balra 
44 (prefix növelés); — — (prefix csökkentés); 

" (bitenkénti tagadás); ! (logikai tagadás); 

— (mínusz előjel); 4 (plusz előjel); 

£ (címe); "(dereferencia); 

new, new [] (dinamikus létrehozás); 

delete, delete[] (dinamikus adatterület törlése); 

0 (C stílusú típuskonverzió) 





H-t (C4-4 pointer-tag operátorok) balról jobbra 











" (szorzás); (osztás); 96 (maradékképzés) balról jobbra 
§ (összeadás); — (kivonás) balról jobbra 
balról jobbra 


Sc (bitenkénti balra léptetés) 
22 (bitenkénti jobbra léptetés) 





s(kisebb); 2(nagyobb); cz (kisebb vagy egyenlő); balról jobbra 


27 (nagyobb vagy egyenlő) 

















A" függelék: A Cs operátorok precedenciatáblázata 





balról jobbra 


- z (egyenlő) !— (nem egyenlő) 





























£ (bitenkénti ÉS) balról jobbra 
" (bitenkénti kizáró VAGY) balról jobbra 
! (bitenkénti VAGY) balról jobbra 
8-8: (logikai ÉS) balról jobbra 
1! (logikai VAGY) balról jobbra 
?: (feltételes) jobbról balra 
z; tsz; /z, 967, tz, —z, cSz, 557; éz; [7 "7 jobbról balra 
(értékadás és értékadással összevont műveletek) 

throw (kivétel dobása) jobbról balra 
, (vessző) balról jobbra 


e ————13Wxg$ugkWeeee 
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, B? FÜGGELÉK 


Fejlesztőkörnyezetek 


Ebben a fejezetben két eszközt mutatunk be. Az e; 
kon népszerű Visual Studio, a másik a POSIX o: 
jedt GNU Compiler Collection C és C4- fordítója. 


gyik a Windows-platformo- 
perációs rendszereken elter- 


B.1. Microsoft Visual Cr 


Napjainkban a Windows platformon történő C-t-t alkalmazásfejlesztés egyik leg- 
kedveltebb fejlesztőkörnyezete a Microsoft Visual Studio 2005.122 A tegdékbak 
több változata létezik. Bár a komolyabb változatokért fizetni kell, a belépő szin- 
tet a Microsoft Visual C-t 2005 Express Edition testesíti meg, amely a Micro- 
soft honlapjáról ingyenesen letölthető!?3 és használható. Már ez a változat is 
rengeteg szolgáltatást nyújt, a fejezetben az eszköz kezelésének alapjaival is- 
merkedhetünk meg. Célunk inkább az elindulás segítése, mint a teljességre való 
törekvés volt. Mivel ez az eszköz angol nyelvű, a könnyebb tájékozódás végett az 
egyes funkciók, felhasználóifelület-elemek nevét nem fordítottuk le magyarra. 


B.1.1. Új solution létrehozása 


Legyen a feladat egy egyszerű C alkalmazás elkészítése, amely a szabványos 
kimenetre kiírja a , Hello world!" szöveget. Első lépésben egy új solutiont kell 
létrehozni. A solution egy munkakörnyezetet fog össze. A solutionön belül 
hozhatók létre a projectek, a forrás- (.c, .cpp) és fejlécfájlok (.h) pedig ezen 
projectekhez tartoznak. Minden project kimenete egy a project típusától függő 
lefordított állomány, amely lehet futtatható program (.exe), statikus könyvtár 
(1ib), dinamikusan linkelhető könyvtár (.dll) stb. Ennek megfelelően egy solu- 
tionhöz akkor célszerű több projectet adni, ha az alkalmazásunkat több kompo- 
nensre bontjuk, és ezeket egy közös környezetben szeretnénk kifejleszteni. 

Új solution megalkotásához gyakorlatilag a solution első projectjét kell lét- 
rehozni: válasszuk ki a , File/New/Project" menüt. A megjelenő ablakban a pro- 
ject típusának válasszuk ki a , Win32-t, template-nek pedig a ,Win32 Console 
Application"-t. A , Name" mezőben adjuk meg a projekt nevét, a s Location" me- 
zőben solutionünk fájljainak elérési útvonalát, , Solution Name" mezőben pedig 
a solution nevét az alábbiaknak megfelelően: 
OEsdte SE 216. deIV BOY TÉS ae 
" Lehetséges, hogy a könyv olvasásának pillanatában m 

el, de annak a kezeléstechnikája valószínűleg nem tér el 


15 A könyv írásakor a következő helyről: http://msdn.microso! 
download/ 


ár a termék újabb verziója érhető 
1 jelentősen az itt leírtaktól. 
ft.com/vstudiofexpress/visualc/ 














nB" függelék: Fejlesztőkörnyezetek 











50. ábra. Új project létrehozása 


Ezt követően az alkalmazásvarázsló jelenik meg, ahol esetünkben megfelel- 
nek az alapértelmezett beállítások, kattintsunk a , Finish" gombra, aminek 
hatására az eszköz legenerálja a kiindulási környezetet. 


B.1.2. A fejlesztés környezete 


A solution létrehozását követően ismerkedjünk meg a fejlesztőkörnyezet 
használatának alapjaival. 
A fontosabb képernyőnézetek a következők: 


s  Dokumentumszerkesztő: a képernyő legnagyobb részét adja, az aktuá- 
lisan kiválasztott forrásfájl, illetve fejlécfájl szövege szerkeszthető itt. Ha 
több fájl is meg van nyitva, tabfülekkel aktiválhatjuk az egyes fájlokat. 
A fenti képernyőn egy forrásfájl van megnyitva, a HelloWorld.cpp. 


s — Solution Explorer: a , Solution Explorer" tabfülre kattintva aktivál- 
ható, a fenti képernyő bal oldalán látható. Ebben a solution alatti pro- 
jecteket, illetve az ezekhez tartozó forrás- és fejlécfájlokat láthatjuk. 
Egy fájlon duplán kattintva az adott fájl megnyílik a dokumentum- 
szerkesztő ablakban. 
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B.1. Microsoft Visual Ces 
CIZZZEIZESEZTEZT TT TOTEEE 4 1] 


Debug z 







( (obai szo0e) 





Sekton Hedowortó (1 project) B// BelloVorid.epp : begins 55) ti 72 § 
k F 2 the entry point for the console spvu:g] 
"1 Heoder Fides 
igyál estek, finciude "stdafx.hr Hi 
2 gy sarceFtes L 
63 Helowortó c20 E 
3 - evre Bint  emain(int arge, TCHAR" argv[]) 
D festett §j j 
return 0; ] 





Fjesdebeíntjon Windav [AC Browsze ! ZJ OLtpk 











e Class View: a , Class View" tabfülre kattintva aktiválható. Ebben a 
solutionhöz tartozó forrás- és fejlécfájlokban definiált osztályok és 
globális függvények nevének felsorolását láthatjuk. Az egyes osztá- 
lyok, globális függvények, tagfüggvények és tagváltozók nevén kat- 
tintva a dokumentumszerkesztőben megnyílik a definíciót tartalmazó 
fájl, és a kurzor a definícióra ugrik. Ez a funkció remekül használható 
a solutionben való navigációra. 


s  Output Window: az , Output" tabfülre kattintva aktiválható. A fordí- 
tás során itt tudjuk nyomon követni a fordítás folyamatát, illetve itt 
kapunk információt az esetleges hibákról és figyelmeztetésekről. 


A varázsló által létrehozott Hello World.cpp forrásfájllal kapcsolatban két ér- 
dekességet figyelhetünk meg, mint az a fenti képen is látható. Az ttinclude 
"stdafx.h" direktíva által beépítettük az stdafx.h fejlécfájlt. Ezt a fejlécfájlt a 
Visual Studio generálja új project létrehozásakor. Az stdafx.h beépíti 
(include) a gyakran használt, de ritkán változó könyvtári és projectfejlécfájlo- 
kat, megteremtve az előfordított fejlécfájlok alkalmazásának feltételeit. Uj 
projectek esetén a fordítási környezet automatikusan előfordított fejlécfájlo- 
kat alkalmaz, aminek célja a fordítás folyamatának felgyorsítása. Egy dolgot 
érdemes ezzel kapcsolatban tudni: alapértelmezésben minden forrásfájl (6 
epp) elején szerepeltetni kell a ttinclude "stdafx.h" sort (a többi ttinclude sor 
előtt), máskülönben fordítási hibát kapunk. Ráadásul a fordítási hiba leírásá- 


ATT 














ból sok esetben nagyon nehéz rájönni, mi okozza a problémát, így erről a ki. 
kötésről célszerű nem elfeledkezni! A másik érdekesség, hogy main függvé. 
nyünk . tmain, char? típusunk pedig .-TCHAR nevet kapott. Ennek célja a 
Unicode fejlesztés megkönnyítése: ha ugyanis nem definiált a UNICODE 
preprocesszor direktíva, akkor preprocesszálást követően a . tmain-ből main, 
a . TCHAR-ból char lesz, a fordító már ezzel dolgozik. Ha pedig definiáljuk 
ezen direktívát, akkor . tmain-ből wmain, a TCHAR-ból wchar t lesz. Ezeket 
a megoldásokat a 12.6.2. A nyelvi környezetek programozása fejezetben tár. 
gyaltuk részletesen. Lényeges, hogy mind az stdafx.h, mind a UNICODE al. 
kalmazása Microsoft-specifikus, így más fejlesztőkörnyezetben nagy valószí- 
nűséggel nem találkozhatunk velük. Amennyiben a projekt létrehozásakor a 
varázslóban az , Empty project" opciót kiválasztjuk, akkor nem generálódik 
.tmain függvény, valamint alapértelmezésben az előfordított fejlécfájl alkal- 
mazása is ki lesz kapcsolva, vagyis minden a megszokott módon fog működni. 


B.1.3. Fordítás, futtatás és nyomkövetés 


A következőkben módosítsuk úgy a  tmain függvény tartalmát, hogy írja ki a 
, Hello world!" szöveget a szabványos kimenetre: 


int .tmainCint argc, -TCHARt argv[]) 






 printfCHeTlo wo! 
getcharO; e; 
"returns 











J 


A , BuildNBuild Solution" menü kiválasztásával (vagy az F7 billentyűvel) s for- 
díthatjuk le (build) a solutiont. Visual Ct-4- környezetben a build alatt a fordí- 
tást és linkelést együttesen értjük, vagyis azt a folyamatot, amelynek ered- 
ményeként elkészülnek a solution projektjeinek kimenetei. Ez esetünkben a 
HelloWorld.exe elkészítését jelenti. Ha a build során a fordító vagy linker hibát, 
figyelmeztetést állapít meg, akkor arról elsődlegesen az , Output" ablakban ér- 
tesülünk. A fordítási hibák esetében az , Output" ablakban a hibaszövegen kat- 
tintva a dokumentumszerkesztőben a kurzor a hibát okozó sorra ugrik. 

A , DebugYStart Debugging" paranccsal (vagy az eszközsáv Pb gombjával, 
vagy az F5 gombbal) elindíthatjuk az alkalmazást nyomkövetési módban. Ha 
az előző build óta valamely forrás- vagy fejlécfájl megváltozott, akkor a futta- 
tást automatikusan build előzi meg. A nyomkövetési módban történő indítás 
lényege az, hogy az esetlegesen beszúrt töréspontoknál megáll a futás, és 
megvizsgálható az egyes változók tartalma.125 Ez a hibakeresés során nélkü- 





124 A beállítástól és a fejlesztőeszköz verzójától is függ, a Ctrl--Shift--B szintén használatos. 

125 Ennek előfeltétele, hogy a kimeneti állomány tartalmazzon nyomkövetési infomációt. Ezt 
legkönnyebben úgy tudjuk elérni, hogy a Debug solution konfigurációt választjuk ki (a 
solution konfigurációkról a következő pontban lesz szó). Új solution létrehozása után au- 
tomatikusan a Debug solution konfiguráció lesz kiválasztva. 
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B.1. Microsoft Visual Ces 


lözhetetlen funkció. Töréspont beszúrásáh 

ban álljunk arra a sorra, amelyikre be BZ kk ee zőékékülő ablak. 
jobb egérkattintásra feljövő menüben válasszuk ki ú BÉL HETE majd a 
point" menüelemet (az F9 billenyű használata jóval ÖLYSZAEÜB) A. rt Break- 
tal ellátott sorokat a sorok elején 8 ikon jelzi. Gyakorláskép A TON SÉRE 
töréspontot a printf sorra, és indítsuk el az alkalmazást (Fő bille slogg Er 
kor a futás a töréspontnál megáll, visszatérhetünk a féjlesáököenyésatnáát 7 


Fia EÓR Vim Project Bid  Dabug Too Wndom  Commungy Hab tsz sa EN 


. 2.0. gl 









ea EE FETEYTVTa 
. Hellowortácpp [97 73 
NER UZTANNTNBT 
) [(aobai scope) Ki JAR A 
5 azaz Hő aroc, TOHAR 1] arg) 
Sekton Helowortó (1 orojec J / ?) TTÖT Ép" 7 
ús 5// Mellolorid.cpp : Defines the entry point for the console appitástie 
5 Ld Hiesder Fios fi 
érsz ] ginciude "atdatx.h" 
2 3 sanceFtes 
Hetowortd epp s 
b. bretsgiss Jínt  tmain(int aegH, TCHAR" argv[]) 
Resdée tt ik ss) 
o OI printf("Hello voridíTn"); 
getchar () ; 


return 0; 
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8 9 agy 000353150 who Helolwortd-exet. tmarrCRTSartug() Une 5834 0xI9bytes  C 
9 aGMO) — 0-DD3A3158"eiftestagpsthetoworátóet a a mehar.  )  Helowaztd.exelvmancRTSZartun) Une 109 c 
Esz] kocák [gj Tres Eg Moses [ggjwotch 1 — [docaastork jöreokports] Aj özpz K. 
ha) 117 ca19 ais ns 





52. ábra. Töréspont alkalmazása 


Ekkor egy változó tartalmát megtekinthetjük úgy, hogy beírjuk a változó ne- 
Vét a , Watch" ablakba (, Watch" tabfüllel aktiválható), illetve a kurzorral rá- 
állunk a változó nevére. Az utóbbi esetben a változó értéke tooltipben jelenik 
meg. Mindkét esetre mutat példát az előző ábra. Lehetőségünk van a prog- 
ramot lépésenként is futtatni a , Debug/Step Over" (F10) vagy a , Debug/Step 
Into" (F11) menüvel. A különbség az, hogy ha az aktuális sor függvényhívás, 
És a függvény forrása elérhető, akkor a , Step Into" belelép a hívott függvény- 
be, a , Step Over" pedig átlépi azt. Néha jól használható a , Step Out funkció 
(Shift4:F11), amivel kiléphetünk az aktuális függvényből, vagyis a futás a hí- 
vó függvény következő soránál áll meg. A ,DebugYStart Debugging" (F5) 
funkcióval a következő töréspontig, illetve kilépésig futtathatjuk a programot. 
Nyomkövetés közben a , Debug/Stop Debugging" menüvel (vagy az eszközsá- 
Von található 4 gombbal) bármikor megszakíthatjuk a program futását. 
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B.1.4. Solutionkezelés 


A solution projectjeihez új forrás és fejlécfájlokat a következőképpen adhatunk 
hozzá. Kattintsunk jobb gombbal a kiválasztott project nevén a Solution Explo- 
rerben, majd a menüben válasszuk ki az ,Add/New Item" menüelemet. A meg. 
jelenő ablakban a , Categories" listában válasszuk ki a , Code" elemet, majd a 
, Templates" listában a , C-t File" vagy , Header File" elemet igény szerint, vé. 
gül pedig a , Name" mezőben adjuk meg az újonnan létrehozandó fájl nevét. Az 
"Add" gomb hatására az új fájl létrejön és hozzáadódik a projecthez. Ha megle- 
vő fájlokat kívánunk hozzáadni a solutionhöz, hasonlóképpen induljunk el, csak 
a felbukkanó menüben az , Add/Existing Item" menüelemet válasszuk ki, ezt 
követően pedig a megjelenő ablakban adjuk meg a felvenni kívánt fájlokat. Ha 
egy új Ct4 osztályt szeretnénk valamelyik projecthez hozzáadni, akkor is 
ugyanígy kezdjük, a felbukkanó menüben az , Add/Class"-t válasszuk ki. A meg- 
jelenő ablakban a , Categories" listában válasszuk ki a ,Ct--" elemet, majd a 
,Templates" listában a , Ct-t Class" elemet, és használjuk az , Add" gombot. Ek- 
kor a , Generic C--- Class Wizard" ablak jelenik meg: 


Generic Cr: Class Wizard - HelloWorld 


Welcome to the Generic C t 4 Class Wizard 





53. ábra. Osztályvarázsló (class wizard) 


Az ablakban legalább az osztály nevét adjuk meg, amelynek alapján az osz- 
tálydefiníciót és a tagfüggvények definícióját tartalmazó ,,.h file" és ,.epp file" 
mezők automatikusan ki is töltődnek. Osztályunk szülőosztályát (ha van) a 
"Base class" mezőben tudjuk megadni. Ha osztályunknak várhatóan lesznek 
leszármazott osztályai, akkor célszerű virtuális destruktort is generáltatni 
számára a , Virtual destructor" jelölőnégyzet kipipálásával. A ,, Finish" gomb 
használatát követően legenerálódik az osztályunk váza. 





Az eszközsávon található legördülőablakban (Debug " ) választhatjuk 
ki az aktuális solution konfigurációt. Minden solutionkonfigurációhoz disédi 
fordító-, linker- stb. beállítások tartoznak. Alapesetben a solution egy Debu 
és egy Release konfigurációval rendelkezik, de újak is létrehozhatók. A Debug 
konfigurációk kiválasztva és buildelve olyan kimeneti (esetünkben .exe) fájl 
keletkezik, amelynél töréspontok alkalmazásával lehetséges a nyomkövetés 
a kimeneti fájl azonban nagyméretű és nem optimalizált. Ezt a konfigurációt 
a fejlesztés és a tesztelés során célszerű használni. Ha már megszabadultunk 
a bugoktól (legalábbis azt hisszük), a telepítéshez a Release konfigurációt cél- 
szerű alkalmazni. Ez kisméretű, optimalizált (így gyorsabb), de nem nyomkö- 
vethető kimenetet eredményez. Az egyes projektekre a , Project Properties" 
ablakban a fordítási, linkelési stb. beállítások minden solutionkonfigurációra 
egyedileg beállíthatók. A , Project Properties" ablak megnyitásához kattint- 
sunk a projekt nevén jobb egérgombbal a Solution Explorerben és válasszuk 
ki a , Properties" menüelemet. 


B.1.5. Néhány hasznos funkció 


A következőkben felsorolunk néhány olyan hasznos szolgáltatást és funkciót, 
amelyet a kezdeti ismerkedést követően célszerű kipróbálni: 


s Display guick info: a dokumentumszerkesztőben egy függvény, vál- 
tozó, osztály vagy struktúra nevére az egérrel ráállva tooltipben rövid 
leírást kapunk róla. Ez általában az adott elem deklarációjának meg- 
jelenítését jelenti. 

s Go to definition: a dokumentumszerkesztőben egy függvény, változó, 
osztály vagy struktúra nevén jobb gombbal kattintva megjelenő menü- 
ből elérhető funkció, mellyel az adott elem definíciójára lehet ugrani. 


s Goto declaration: a dokumentumszerkesztőben egy függvény, vál- 
tozó, osztály vagy struktúra nevén jobb gombbal kattintva megjelenő 
menüből elérhető funkció, mellyel az adott elem deklarációjára lehet 
ugrani. 


s Display word completion: amikor a dokumentumszerkesztőben el- 
kezdünk beírni egy nevet, a CtrltSpace megnyomására megjelenik az 
adott hatókörben érvényes, az általunk beírt névvel kezdődő definíciók 
listája. A definíciók között a kurzorbillenyűkkel mozoghatunk, és az 
Enter billentyűvel választhatjuk ki a beszúrni kívánt elemet. Ha az 
adott névvel csak egy definíció kezdődik, a lista meg sem jelenik, a de- 
finíció automatikusan beszúródik. Az alábbiakban erre látunk példát: 
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54. ábra. Automatikus szókiegészítés 


Ez a funkció óriási segítség a mindennapi munkában. Lehetővé teszi, 
hogy hosszú, beszédes függvény-, osztály- és változóneveket használ- 
junk, mégse kelljen azokat a használat során végig begépelni. 


s Display parameter description: a dokumentumszerkesztőben egy 
függvény, illetve tagfüggvény nevét követően a ,,("-et leírva tooltipben 
megjelenik a függvény paraméterlistája (ahogy az a függvénydeklará- 
cióban szerepel). Ez is nagy segítség, hiszen amennyiben egy függvény 
meghívásakor nem emlékszünk pontosan a megadandó paraméterek- 
re, nem kell kikeresni a dokumentációból. 


s — Display object member list: a dokumentumszerkesztőben egy struk- 
túra-, illetve objektumváltozó nevét követően a ,.."-ot leírva automati- 
kusan listázódnak a tagfüggvényei és a tagváltozói. Ugyanez igaz, ha 
pointerváltozó nevét követően ,,-2"-t írunk. 


e Error list: a fordítási és linkelési hibák, figyelmeztetések táblázatos 
listája. A , View/Other Windows/Error List" menüvel jeleníthető meg. 
Egy adott során duplán kattintva az adott hibára, illetve figyelmezte- 
tésre ugorhatunk. 








B.1.6. Dokumentáció 


A Visual Studio — és ezzel együtt a Visual C-t — környezet d, ációj 
Microsoft Developer Network Library (MSDN Tibragg) részeként érté a Ae 
MSDN Library teljes verziója valamennyi fejlesztői Microsoft technológia és 
kapcsolódó eszköz dokumentációját tartalmazza. Az MSDN Library két for- 
mában érhető el. Egyrészt online,!26 másrészt telepíthető formában. Ez utób- 
biból a Microsoft Visual C--t 2005 Express Editionhöz egy ingyenes — a fej- 
lesztőeszközhöz kapcsolódó — verzió is letölthető, amit a Microsoft Visual C4-4 
2005 Express Edition letöltése során célszerű is megtenni. A telepítést köve- 
tően a dokumentáció többek között a Visual Ct4 ,Help" menüjéből érhető el 
( Index", ,Search" vagy , Contents"). Lehetőség van a dokumentáció Visual 
Studióban történő integrált megjelenítésére, illetve önálló alkalmazásként va- 
ló futtatására. Az alábbiakban az utóbbira mutatunk példát: 


printf, .printf1, wprintf, .wprintf. 1 : Microsoft Visual Studio 2005 Express Editions Documentatíon - Microso. 


RunrTime Ubrary Reference 

printf, printf. 1, wprintf, . wprintf.1 
Sne.Alzo Examole 

A Collapse All v] Language Filter: Ce 


Print formatted output to the standard output stream. More secure versions are 
available, see printf s, printf : I. woninté s, mprintf : I. 


int printt( 
const char "format [, 
arguzent)... 
hé 
int printf 1( 
const char "format, 
locale t 20cale [/ 
arguzent)... 
Cst See prntng[cs4] 46 
viták int wprintf( 
kermigápízdveűjes ej const vchar t "format [, 
Windows Forró See prirteg [wedovrs Form ezgunent]. 
erréng(€44) 1; 
to corsole Ant wprintf 1( 
9 (visual Base) vi cönst vchar t "format, 


Öéeterts (járda EZ Fovortei 1ocale t 206426 [/ 


1 Resdts for printf function 





55. ábra, MSDN Library 
A dokumentáció használatának alapelvei a következők: 


s  Contents: a tartalomjegyzéket jeleníti meg, ebben egy adott témát 
kiválasztva megjelenik a tartalma. 





"6 A könyv írásának pillanatában a http:/msdn. microsoft. comílibrary/ címen. 
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B" függelék: Fejlesztőkörnyezetek 
e Index: a dokumentációhoz tartozó kulcsszavak rendezett listájában 
kereshetünk. Az egyik leghasznosabb funkció. Az MSDN Library 
online változatában nem elérhető. 


e Search: a dokumentáció teljes szövegében keresi az általunk meg- 
adott szavakat. 


B.2. A GNU Cst fordító 


A GNU Compiler Collection (http://gcc.gnu.org/)) C és C-t fordítói a POSIX 
platformok legelterjedtebb fordítói, és számos grafikus fejlesztőkörnyezet 
alapjai. Ezért ebben a fejezetben nagyon röviden bemutatjuk az eszköz leg- 
fontosabb szolgáltatásainak használatát. A GNU Compiler Collectiont megva- 
lósító program neve gcc, amely parancssorból érhető el. Ez az eszköz különbö- 
ző nyelvű programok lefordítására képes, amelyet vagy a forrásállomány ki- 
terjesztése, vagy a -x kapcsoló paramétere alapján határoz meg. Az egyes 
nyelvekhez külön segédprogramok tartoznak, amelyek lényegében a gcc se- 
gédprogramot paraméterezik fel. A C4- fordító neve g-t-t, illetve néhány plat- 
formon ct-t. Hagyományosan a C fordító neve is gcc (ez a GNU C Compiler 
rövidítése volt régen), ezért a C fordítóra nincs külön elnevezésű segédprog- 
ram, a C forrásállományokat a gcc segédprogrammal fordítjuk. 

Ha adott egy pelda.c nevű C forrásállományunk, amelyből szeretnénk egy 
pelda nevű futtatható állományt készíteni, akkor az eszközt az alábbi módon 
paraméterezzük: 





A -o kapcsolóban az , 0" az output (kimenet) rövidítése, vagyis ezzel a kapcsoló- 
val adhatjuk meg a kimeneti állományt. A gcc a .c végződésű állományokat C 
fordítóval fordítja, C szintaxis alapján. A gcc ugyanakkor felismeri a cpp, CPP, 
ett, cc, cxx, cp, C végződésű állományokat, és ezeket C-t fordítóval fordítja. 
Ugyanakkor a Szabványos Ct-- Könyvtár használatához szükséges libstdet-t 
programkönyvtárat nem linkeli hozzá az alkalmazáshoz. Programkönyvtár lin- 
kelését a -/ kapcsolóval végezzük, és elhagyjuk a lib előtagot. Vagyis, ha egy 
Cs nyelvű forrásállományt szeretnénk lefordítani, akkor a következő paran- 
csot adjuk ki: 


EEG ÉRŐSZTSGT KE KOTNEK Ó E ZO SUM EBEK 


A gtt segédprogram a gcc-vel ellentétben automatikusan hozzálinkeli a 
szabványos könyvtár használatához szükséges programkönyvtárat, és alapér- 
telmezésben a C nyelvű forrásállományokat (.c végződés) is Ct- kódként Ctt 
fordítóval fordítja. A g1-t paraméterezése nagyon hasonló a gcc paraméterezé- 
séhez. Így a pelda.cpp-t g4--szal az alábbi módon fordíthatjuk: 
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Útmutató: 
— Cs programok fordításához használjuk a gr segédprogramot! 


— C nyelvű forrásállományt csak akkor fordítsunk grr-szal, ha valamilyen okból Ó 
2 v9 Fi 2 ei 8 c Jj 
ként szeretnénk lefordítani, egyébként használ ljuk a gcc segédi zs zug 488 





Ha több állományunk is van, akkor először fordítanunk kell őket, utána lin- 
kelnünk. A fordítást a -c (,compile") kapcsolóval adjuk meg. A fordítás ered- 
ményeképpen egy, a forrásállománnyal azonos nevű, de .o végződésű, úgyne- 
vezett tárgykódú állomány (object file) áll elő. Ezeket a tárgykódú állomá- 
nyokat kell összelinkelnünk a futtatható állományhoz. Csak akkor tudunk 
futtatható állományt létrehozni, ha valamelyik forrásállományban megtalál- 
ható a main függvény, de csak egyben. 





A fenti parancsok első sora a pelda1.cpp forrásállományt fordítja le, ezáltal egy 
peldal.o állományt hoz létre. A második sor ugyanezt végzi el a pelda2.cpp ál- 
lományra. A harmadik sor a peldal.o és a pelda2.o tárgykódú állományokból 
készíti el a pelda nevű kimeneti állományt. 

A tárgykódú állományból az ar segédprogrammal készíthetünk statikus 
programkönyvtárakat. Az előző példával ellentétben itt azt feltételezzük, hogy 
sem a pelda1.cpp, sem a pelda2.cpp nem tartalmaz main függvényt, mert az ál- 
talában a programkönyvtárat használó kódban található. 


"ár rcs Tibpelda.a peldal.o peldadzó 4 ge Tessa 


A statikus könyvtárakat a már említett módon a -! kapcsolóval linkelhetjük 
hozzá a programunkhoz. Az alábbi példában a pelda.o tartalmazza a main 
függvényt, amely a futtatható állomány belépési pontja. A -L kapcsoló a prog- 
ramkönyvtárak helyének elérési útvonalát adja meg. Ha ez az aktuális 
könyvtár, akkor használhatjuk a pontot az aktuális könyvtár jelölésére, ame- 
lyet szóköz nélkül írunk a -L kapcsoló után. 


TE" pelda pelda.o -Npelda Abe olte 7 regbdtltelzote Ban stesetbett 


Ha a források egy részét szeretnénk C fordítóval, más részét C-t fordítóval 
fordítani, akkor az alábbi példa szerint érdemes eljárnunk. 
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Útmutató: Ha vegyesen C és Cr fordítóval fordított tárgykódú állományaink vannak, a (in. 
kelést grr-szal végezzük! 





Végül megjegyezzük, hogy manapság a fent bemutatott segédprogramokat 
már ritkán használják közvetlenül. Számos további segédprogram (make, auto- 
make) képes többé-kevésbé automatikusan felparaméterezni a fordítót, nem is 
szólva a grafikus fejlesztőkörnyezetekről (mint például az ingyenesen letölt. 
hető KDevelop, www.kdevelop.org). Ugyanakkor a POSIX operációs rendsze- 
rek világában igen általános, hogy ezek a fejlesztést gyorsító eszközök is az 
ismertetett segédprogramokat paraméterezik fel. 


, C?" FÜGGELÉK 


Áttérés C nyelvről 
C-t nyelvre 


Az alábbiakban a C-ről a Ct4 nyelvre áttérést segítendő táblázatszerű 

megadtuk néhány gyakran használt C nyelvi és könyvtári elem C-- n EST 
megfelelőjét. Bár a C nyelvű megoldás használható C-t-t nyelven is -hi tése 
Ct- nyelv visszafelé kompatibilis a C-vel —, a C4-4 megoldás minden öáttbe 6 
átláthatóbb, könnyebben karbantartható kódot eredményez, és kevesebb hi 
balehetőséget rejt magában. 4 4 


Általános célú funkciók 























struct class 
malloc/ free new / delete A Ct-- operátorok a 
newl[ ]/delete[ ] helyfoglalás mellett 
meghívják a konstruk- 
tort és a destruktort 
fI0f...malloc..) class C A dinamikus objektu- 
f201...free...) ( mok felszabadítása au- 
C0£...new...) tomatikus destruktor- 
500(...delete...) hívással. Az erőforrások 
E élettartamával azonos 
élettartamú objektumok 
használata 
if (fu) —success) try ( fvO;) Visszatérési értékként 
catch () ( átadott hibakód helyett 
kivételkezelés 
Hidefine MAX 300 const int maxz300; Makrók helyett kons- 
tansok 
fidefine MAX(a,b) ... inline ... max(...) b. Az inline függvények ga- 


rantálják az egyszeri pa- 
raméterkiértékelést 

















nC" függelék: Áttérés C nyelvről Cst nyelvre 









Referencia szerinti 
paraméterátadás 


void f(int" pa) void f(intdta) 





C stílusú sztringműve- 
letek helyett a string 
tagfüggvényei vagy glo- 
bális algoritmusok 





strepy , strlen 








int max(int a, int b) f ...) template sclass TT Sablonfüggvények 
double max(double a, magxíT a, T b) (...) 

double b) £...? 

setDatel(int month) ?? setDate(int month) Függvénynév- 


setDateX(sturct Date d) () setDate(Date d) 8? túlterhelés eltérő függ- 


vénynevek helyett 
Ce e e ket sekát ka ELSE Kor aA 


Adatstruktúrák 






C stílusú sztring helyett 

















char" string osztály 
string osztály 

char"" vectorsstring2 C stílusú sztringek dina- 
mikus tömbje helyett 
sztringvektor 

int" vectorSint2 Dinamikus tömb 

saját láncolt lista listsz Láncolt lista 

gsort sort(v.begin(), v.end0)) Sorrendezés tömbben 

INT MAX numeric limitscintos: Adattípusok jellemző 

max() konstansai a 

numeric. limits 
sablonban 


ÉRNEK. a ee NT] 








act 
vo 
printf cout cz 
printf( "h4.2f"..); coutcssetw(4)cz 
setprecision(2) cx. 
czendl; 
fopen fstream s; 
fwrite/fread s.read/s.write 
fgetchar/fputchar s.get/s.put 
fscanf s55 
fprintf s az 
sprintf/sscanf stringstream sstrm ; 


ssirmsz 
ssirm:22 


: Áttérés C Ces 


A cout használatakor 
fordítási idejű ellenőrzés 
történik 


Formátumsztringek he- 
lyett [/0 manipuláto- 
rok, tagfüggvények 


Bináris olvasás/írás 
Egy bájt olvasása/írása 
Formázott beolvasás 
Formázott kiírás 


Sztringbe írás/sztringből 
olvasás: sztringadat- 
folyamok 




















Kislexikon 


absztrakt osztály (abstract class) Olyan osztály, 


amely tartal, g 
tán virtuális tagfüggvényt. maz legalább egy tisz. 


adatfolyam (stream) Olyan osztály, amely formázott adatbeolvasást és -kiírást tesz 
lehetővé. 


adatfolyam-iterátor (stream iterator) Az adatfolyamok bejárását lehetővé tevő iterátor, 


adatrejtés (data hiding) Valamennyi objektumorientált nyelv, így a Ct- is megfelelő 
kulcsszavakkal lehetővé teszi az osztályok tagváltozóihoz és tagfüggvényeihez való 
hozzáférés szabályozását. A védett/rejtett tagváltozók/tagfüggvények csak a defi. 
níciót tartalmazó osztály tagfüggvényei számára hozzáférhetők. 


aggregáció (aggregation) Tartalmazást kifejező asszociáció. 


alacsony helyettesítő (low surrogate) Az UTF-16 karakterreprezentációs formátum- 
nál a 16 biten már nem ábrázolható számok első 16 bitje. 


alapértelmezett függvényargumentum (default function argument) A Ct4 nyelv- 
ben a függvényargumentumoknak alapértelmezett érték adható meg. Az alapér- 
telmezett értékkei rendelkező argumentumoknak nem kötelező értéket adni a hí- 
vás során. 


alapkarakter (base character) A Unicode szabványban az összetett karakter első 
komponense. 


alaposztály (base class) Id. öröklés 


általános beszúró (general inserter) Az STL-ben olyan iterátoradapter, amely lehe- 
tővé teszi a tároló tetszőleges pozíciójába történő beszúrást. 


általánosítás (genera lization) Id. öröklés 


amortizált komplexitás (amortized complexity) Az a legrosszabb esetet alapul vevő 
komplexitás, amely csak bizonyos műveletszám fölött számolt átlagra érvényes. 


arculat (facet) Az STL-ben a nyelvi környezet funkcióit megvalósító osztályok. 


argumentumfüggő (Koenig) névfeloldás (Koenig lookup) Névterek esetében a for- 
dító a függvények/operátorok névfeloldása során azon névterekben is keres, ame- 
lyekben a paramétereinek típusai definiáltak. 

Asszociáció (association) Az UML osztálydiagramon két osztály között lévő kapcsolat 
egyik fajtája. fan 
ASSzociációs osztály (association class) Az UML osztálydiagramon az asszociáció tu- 

Jajdonságait egységbe záró osztály. ! 
Asszociatív tároló (associative container) Az STL-ben olyan tároló, amelyekben az 
elemek sorrendjét a tároló határozza meg. 














Kíslexikon 





attribútum (attribute) UML-ben az osztály tagváltozói. 


bájtsorrendjelzés (byte order mark — BOM) Microsoft platformokon a használt 
Unicode transzformációs formátumot jelölő bájtsorozat 


beágyazott definíció (nested definition) A Ctt nyelv azon lehetősége, mely támogatja 
enumeráció-, osztály-, struktúra- és típusdefiníciók (typedef) osztálydefiníción be. 
lüli megadását. 


beágyazott enumerációdefiníció (embedded enumeration definition) Id. beágyazott 
definíció. 


beágyazott osztálydefiníció (embedded class definition) Id. beágyazott definíció. 
beépített típus (built ín type) Azon elemi típusok, melyek részei a C4-t nyelvnek, 


behelyettesíthetőség (substítutabilíty) Az objektumorientáltságnak azon elve, mi. 
szerint egy speciálisabb osztály objektuma bárhol felhasználható, ahol egy általá- 
nos osztály objektuma, azaz a speciálisabb osztály példányai helyettesíthetik az 
általánosabbakéit. 


beszúró (inserter) Id. beszúróiterátor 


beszúróiterátor (insert iterator) Az STL-ben olyan iterátoradapter, amely lehetővé 
teszi a tárolóba történő beszúrást. 


beviteli iterátor (input iterators) Az STL-ben olyan íterátor, amelyekre értelmezet- 
tek a t, -2, tt ——, 1- operátorok és a másolókonstruktor. 








beviteliadatfolyam-iterátor (istream iterator) Olyan beviteli iterátoradapter, amely 
a támogatja az íterátoralapú hozzáférést beviteli adatfolyamokhoz. 


bináris kupacnak (binary heap) Az STL-ben az olyan teljes bináris fa, amelyben a 
szülők nagyobbak vagy egyenlőek, mint a gyermekeik. 


deklarációs régió (declaration region) Egy forrásfájl adott pontjára vonatkozó dekla- 
rációs régió a forrásfájl azon része, amelyben az adott pontban deklarált változó 
elérhető. 


destruktor (destructor) C-4-4--ban közvetlenül az objektum megsemmisülése előtt auto- 
matikusan meghívódó függvény. 


egybájtos karakterkódolás (single-byte encoding) Olyan karakterreprezentáció, 
ahol egy karaktert egy bájton tárolunk. 


egyenlőség (eguality) Az STL-ben az —— operátort használó összehasonlítás. 


egységbezárás (encapsulation) Az objektumorientált nyelvek és így a Ctt nyelv azon 
alapelve, amely lehetővé teszi az adatok és a rajtuk értelmezett műveletek egy- 
ségbezárását, vagyis egy adott típuson belüli megadását. 


ekvivalencia (eguivalence) Az STL-ben egy szigorú gyenge rendezésnek megfelelő 
műveletet használó összehasonlítás. 


előre beszúró (front inserter) Az STL-ben olyan iterátoradapter, amely lehetővé teszi 
a tároló elejére történő beszúrást. 


492 








SZSZK e aa — 

előreléptető iterátor (forward iterator) Az STL-ben ol. 
mezettek a t, 2, tt 
konstruktor. 


ja r 1 lyan iterátor, amelyekre értel. 
7 operátorok és az alapértelmezett, illetve a másoló. 





értékadás (assignment) Egy változónak érték adása a létrehozást követően. 


explicit függvénysablon példányosítás (explicit function template instantiation) 
Egy függvénysablon felhasználása a sablonparaméterek explicit megadásával. 


first in, first out (FIFO)-tároló Olyan tároló, ahol az elemek kivétele a betevés sor- 
rendjében történik. 


folytonos memóriaterületen elhelyezkedő tároló (contiguous memory container) 
Az STL-ben olyan tároló, amely folytonos memóriaterületen tárolja az elemeit. 


fordítóiterátor (reverse iterator) Olyan iterátoradapter, amely fordított sorrendben 
járja be az elemeket. 


friend (barát) függvény (friend function) Az egyes osztályok a friend kulcsszó hasz- 
nálatával feljogosíthatnak globális függvényeket, illetve más osztályokhoz tartozó 
tagfüggvényeket a védett tagjaikhoz való hozzáférésre. Az ilyen függvényeket 
friend (barát) függvényeknek nevezzük. 


friend (barát) osztály (friend class) Az egyes osztályok a friend kulcsszó használatával 
feljogosíthatnak más osztályokat a védett tagjaikhoz való hozzáférésre. Az ilyen 
osztályokat friend (barát) osztályoknak nevezzük. 


funktor (functor) Id. függvényobjektum 


függvényadapter (function adapter) Az STL-ben függvényobjektumok összekombiná- 
lását lehetővé tévő sablon. 


függvények kivételspecifikációja (exception specification for functions) Ct-t függ- 
vények deklarációjának részeként adható meg. Definiálja, hogy az adott függvény 
milyen kivételeket dobhat. 


függvényobjektum (function object) Olyan osztály példánya, amelyben a zárójel ope- 
rátor túl van terhelve. 

függvénysablon (function template) Olyan Ct4 nyelvi konstrukció, amely lehetővé 
teszi, hogy egy függvény bizonyos elemeit (pl. a függvényparaméterek típusát) pa- 
raméterként kezeljünk és a függvénysablon felhasználása során adjuk meg. 


függvénysablon-specializáció (function template specialization) Függvénysablon 
adott paraméterbehelyettesítésére speciális implementáció megadása. 
Az algoritmusok és az adatstruktú- 


ösöri eric amming) Ó 
generikus programozás (generic progr: § zetartozó 


rák általános és absztrakt definíciója, amely lehetővé teszi, hogy öss: 
programozási feladatokat egyszerre végezzünk el. Az STL egyik alapelve. f 
hatókör operátor (scope operator) Egy adott definíció minősített nevének megadására 
szolgál. Ld. még minősített név. at 
hátra beszúró (back inserter) Az STL-ben olyan iterátoradapter, amely lehetővé teszi 
a tároló végére történő beszúrást. 


493 














Kislexikon 





helyettesítőpár (surrogate pair) Az UTF-16 szabványban a 16 bitnél hosszabb kód. 
pontok tárolási módszere. 
hívási verem visszacsévélése (stack rewind) Egy kivétel dobásakor annak elkapásá. 


ig a függvények hívási láncában felfelé haladva az egyes függvények lokális válto. 
zói felszabadulnak. Ezt a folyamatot a hívási verem vissza-csévélésének nevezzük, 


honosítás (localization) Egy kultúrafüggetlenül megírt szoftver adaptációja egy adott 
kultúrára. 


I/O manipulátor (I/O manipulator) Az adatfolyamok formázásának beállítására 
használható függvények vagy függvényobjektumok. 


implementáció öröklése (implementation inheritance) Ha egy osztály leszármazik 
egy másikból, következik, hogy örökli a szülő tagváltozóit és tagfüggvényeit, így 
azokat szabadon felhasználhatja. Az öröklés alkalmazásának ezen vonzatát az 
implementáció öröklésének nevezzük. 

implicit függvénysablon példányosítás (implicit function template instantiation) 
Egy függvénysablon felhasználása a sablonparaméterek megadása nélkül. Ekkor a 
fordító következteti ki a sablonparamétereket a megadott függvényparaméterek 
alapján. 


inicializálás (inicialization) Egy változónak kezdőérték adása a létrehozás során. 


inkompatibilis típusok (incompatible types) Olyan típusok, amelyeken nem értel- 
mezettek reprezentáció szinten egymás műveletei. 


inline függvény (inline function) Olyan függvény, melynek törzse behelyettesítődik a 
hívás helyére. 

internacionalizáció (internationalization) Szoftver alkalmassá tétele az egyes kultú- 
rákhoz történő adaptálásra. 


iterátoradapter (iterator adapter) Az STL-ben olyan csomagolóosztály, amely lehetővé 
teszi az iterátorokon keresztüli hozzáférést egy iterátorinterfésszel nem rendelkező 
adatstruktúrához. 


jelzőbit (flag) Beállítások 0 vagy 1 értékeit tároló bit. 


kapacitás (capacity) Az STL-ben a vector és a string által lefoglalt memóriaterület 
mérete elemszámban kifejezve. 


karakterjellemző (character trait) Sablon adatstruktúra, amely STL sztring osztá- 
lyok (és számos be- és kimenetiadatfolyam-sablon) számára leírja az alapvető tí- 
pusdefiníciókat, a másolás, értékadás, keresés, méretszámítás műveleteit és az ál- 
lományvége-jelet (EOF). 

kétirányú generálás (round-trip engineering) A kódgenerálás és a kódvisszafejtés 
együttes neve. 

kétirányú iterátor (bidirectional iterator) Az STL-ben olyan iterátor, amelyekre ér- 
telmezettek a t, -3, tt——, —, 1- operátorok és a másolókonstruktor. 


kimeneti iterátor (output iterators) Az STL-ben olyan iterátor, amelyekre értelme- 
zettek a " és a t-t operátorok és a másolókonstruktor. 
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kivétel (exception) A Cs.P nyelvben kivétel a tároto külesszóval dobható; ennek para. 


métereként adható meg a kivétel, amely a ki, j r 
(pl. hiba oka) a kivételkezelő számára. vételes helyzetről hordoz információt 


kivételkezelés (exception handling) Olyan C4-t nyelvi konstrukció, 
szi kivételes helyzetek (pl. hibák) jelzését és kezelését aaz lehetővé te. 


kódburjánzás (code bloat) Ha egy sablont — legyen az függvénysabl. Á 
sablon — több paraméter-kombinációval használunk (pl. TiSHÉ FE edblee, 
stb.), kasza sztk vonatkozóan legenerálódik a sablon tagfüggvényeinek kódja, 
ami a generált kód méretének növekedéséhez vezet. Ezt szoká: k j 
vagy kódfelfúvódásnak nevezni. 4 c SAGGELÁREKROAK 


kódfelfúvódás (code bloat) Id. kódburjánzás 
kódgenerálás (forward engineering) Az a művelet, amely modellből készít kódot. 


kód-modell szinkronizálás (code-model synchronization) Olyan kódvisszafejtési mű- 
velet, amely a modellnek a legutóbbi kódvisszafejtés óta történt változásait is fi- 
gyelembe veszi. 


kódpont (code point) Az Unicode szabványban egy karaktert egyértelműen azonosító 
egyedi egész szám. 
kódvisszafejtés (reverse engineering) Az a művelet, amely kódból készít modellt. 


kombinálókarakter (combining character) A Unicode szabványban az összetett ka- 
rakter első komponense. 

kompozíció (composition) Az UML osztálydiagramon az asszociáció egy fajtája. 

konstans tagfüggvény (const member function) Olyan tagfüggvény, amely az objek- 
tum állapotát nem változtatja meg. 

konstruktor (constructor) Az objektumorientált programozásban az osztály automa- 
tikus inicializálását elvégző függvény. 

konstuktorinicializálási lista (constructor initializer list) A Ct-4-ban az osztály tag- 
változóit és örökölt tagváltozóit inicializáló paraméterlista a konstruktor fejlécében. 

konverziós konstruktor (conversion constructor) Ct-t-ban az egyparaméterű konst- 
ruktor. 

korlátozó öröklés (restriction) Olyan öröklés, ahol az egyfajta kapcsolat csak bizo- 
nyos kényszerfeltételek mellett igaz. 


közönséges karakter (ordinary character) C/Ct-t nyelven a char típusban tárolt ka- 
rakter. 

latin kiterjesztés (latin extended) Az ASCII kódtábla kiegészítése különböző európai 
nyelvekre. 

leszármazott osztály (derived class) Az objektumorientált programozásban olyan 
osztály, amely egy másikból örököl. 1 

magas helyettesítő (high surrogate) Az UTF-16 karakterreprezentációs formátumnál 
416 biten már nem ábrázolható számok második 16 bitje. 
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másolókonstruktor (copy constructor) C4- nyelven olyan konstruktor, amely egyetlen 
paraméterének típusa az adott osztály konstans vagy nem konstans referenciája, 


maszk (mask) Olyan bitminta, amely meghatározza, hogy egy bítsorozatban mely bi. 
tekhez férünk hozzá. 

mély másolás (deep copy) Az adatsruktúrának olyan másolata, amely az adatstruktúra 
dinamikusan foglalt memóriaterületeit ís lemásolja. 

metódus (method) UML-ben az osztály tagfüggvényei. 


minősített asszociáció (gualified association) Olyan asszociáció, ahol a céloldalon lévő 
osztály egy attribútumát használjuk azonosításra. 






ágyazott definíciók 


minősített név (gualified name) Osztálydefinícióba és névté. 
td::string). 


elérési útvonala", a :: hatókör operátorral adható meg (pi 

minősítő (gualifier) Minősített asszociációnál a minősítéshez használt attribútum neve. 

modell-kód szinkronizálás (model-code synchronization) Olyan kódgenerálási műve- 
let, amely a modellnek a legutóbbi kódgenerálás óta történt változásait is fíigye- 
lembe veszi. 

mutable- (mutable) Olyan tagváltozó, amely konstans tagfüggvényből is megváltoz- 
tatható. 

nemmódosító algoritmus (nonmodifying algorithm) A C$t szabványos sablonkönyv- 
tárában azok a függvények, amelyek nem módosítják a bemenetként megadott 
tartományt. 

névelferdítés (name mangling) A Ct-t fordítóknak az a függvénynévátalakító mecha- 
nizmusa, amelyek segítségével a különböző argumentumlistájú, de azonos nevű 
függvények különböző nevűek lesznek. 

névtér (namespace) A névterek felhasználásával a különböző definíciók névhierarchi- 
ába szervezhetők, így megoldható segítségükkel a definíciók logikai csoportosítása. 

nyelvi környezet (locale) 1. Az operációs rendszer kultúrafüggő beállításait reprezen- 
táló adatstruktúra. 2. Ct4-ban az operációs rendszer kultúrafüggő beállításaihoz 
való rendszerfüggetlen hozzáférést támogató osztály. 

objektum (object) Az objektumorientált nyelvek alap építőköve, egy entitás, az adott 
osztály egy példánya. 

operátorok túlterhelése (operator overloading) A C--4 nyelv azon lehetősége, hogy a 


Ct4 operátorainak többségére vonatkozóan saját típusaink esetén értelme- 
zést/implementációt adhatunk meg. 


osztály (class) Azonos tulajdonságú és viselkedésű objektumok adatszerkezete. 


osztálysablon (class template) Olyan C-4-- nyelvi konstrukció, amely lehetővé teszi, 
hogy egy osztály bizonyos elemeit (pl. egy tároló esetén az elemek típusát) paramé- 
terként kezeljünk és az osztálysablon felhasználása során adjuk meg. 


osztálysablon-specializáció (class template specialization) Id. sablonspecializáció 


öröklés (inheritance) Az osztályok közötti általánosítás/specializáció (más nevén ,egy- 
fajta") kapcsolattípus a C4-4 nyelvben örökléssel fejezhető ki. A leszármazott Osz- 
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ee Költérttit 
tály (gyerekosztály, speciálisabb osztály) örökli a szülő osztál! 
lánosabb osztály, ősosztály) tagváltozóit és tagfüggvényeit. S vsstsszegságatága 


ősosztály (ancestor class) Id. öröklés 


összetett karakter (precomposed/composed/composite ch; 5 
ványban a két karakter összetételével iogádótökaralítás es svdba UA elb 


példányosítás (instantiation) Osztályból objektumpéldány létrehozása. 


pointer-tag operátor (pointer-to-member operator) A Ct- olyan operátora, amely az 
objektumából vagy az arra mutató pointerből és az ol A 4 


bjektum ej j ó 
pointerből elérhetővé teszi a tagot. ) gy tagjára mutató 


polimorfizmus (polymorphism) A C4- ban azt a jelenséget, hogy az ősosztály típusú 
pointer mutathat bármelyik leszármazott típus példányára is, polimorfizmusnak 
nevezzük. 


predikátum (predicate) A Ct-4 szabványos sablonkönyvtárában a bool értékkel visz- 
szatérő függvényt nevezik így, 


rendezett tartományt feltételező algoritmus (sorted range algorithm) A CH 
szabványos sablonkönyvtárában azok a függvények, amelyek rendezett tarto- 
mányt várnak bemenetként. 


rendezőkulcs-generálás (sort key generation) A sztringekből képzett olyan sztringek, 
amelyekre a karakterenkénti összehasonlítás ugyanazt az eredmény adja, mint a 
kultúrafüggő összehasonlítás az eredeti sztringekre. 


részleges sablonspecializáció (partial template specialization) Függvény- vagy osz- 
tálysablon adott paraméterbehelyettesítésére speciális implementáció megadása. 
Csak a paraméterek egy részhalmaza kerül megkötésre, a többi továbbra is para- 
méterként kezelt. 


sablon (template) 0-4-4 sablonok alatt olyan osztálysablonokat és függvénysablonokat 
értünk, melyek esetében az adott osztály, illetve függvény definiálásakor bizonyos 
elemeket nem adunk meg, hanem paraméterként kezelünk. Ezen paraméterek 
megadása explicit vagy implicit módon az adott osztálysablon, illetve függvénysab- 
lon felhasználásakor történik. 


sablonparaméter (template parameter) Id. sablon 


sablonspecializáció (template specialization) Függvény: vagy osztálysablon adott 
paraméterbehelyettesítésére speciális implementáció megadása. 


sekély másolás (shallow copy) Egy adatstruktúra bitenkénti átmásolása. 


sorrendváltoztató algoritmus (mutating algorithms) A Ctt szabványos sablon- 
könyvtárában azok a függvények, amelyek megváltoztatják a bementként kapott 
tartományban az adatok sorrendjét. 


specializáció (specialization) Id. öröklés 
osztály valamennyi objektumára 


Statik: ü i function) Az j 
us tagfüggvény (static member func. a kövesztülítabjektutnenálkül ta 


közös, osztályszintű tagfüggvény. Az osztály nevi 
hívható, 
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statikus tagváltozó (static member variable) Az osztály valamennyi objektumára közös, 
osztályszintű tagváltozó. Az osztály nevén keresztül, objektum nélkül is elérhető, 

Szabványos Ctt Könyvtár (Ctt Standard Library) A Ctt szabvány által előírt osz. 
tályok és függvények gyűjteménye. 

szabványos Ct-4t sablonkönyvtár (Standard Template Library) A szabványos Cr 
könyvtárnak az algoritmusokat, tárolókat, [/D osztályokat és a hozzájuk kapcsolódó 
egyéb elemeket tartalmazó része. 


származtatás (derivation) Id. öröklés 


szekvenciális tároló (seguence container) Az STL-ben olyan tárolók, amelyekben az 
elemek sorrendjét a tároló felhasználója határozza meg. 


, szeletelés kapásból? (slicing-on-the-fly) Automatikus konverzió az ősosztály típusá- 
ra, amikor céltípusba csak a leszármazottnak az ősosztálytól örökölt része kerül. 


szerepnév (role name) Az UML asszociáció két végén található név, amely azt jelzi, 
hogy az egyes osztályok milyen szerepben vesznek részt a kapcsolatban. 


szigorú gyenge rendezés (strict weak ordering) Antiszimmetrikus, tranzitív és 
irreflexív rendezőművelet. Az STL használja két elem sorrendjének vagy ekviva- 
lenciájának eldöntésére. 


tagfüggvény (member function) Olyan függvény, ami egy osztályon belül definiált. Az 
osztály objektumaira hívható. 


tagfüggvény-sablon (member function template) Olyan függvénysablon, amely egy 
adott osztály vagy osztálysablon tagfüggvénye. 


tagváltozó (member variable) Olyan változó, ami egy osztályon belül definiált. Egy 
osztály tagváltozói határozzák meg az objektumainak felépítését. 


tárgykódú állomány (object file) A C/C--t fordító kimenete. 
tároló mérete (size of the container) Az STL-ben a tároló elemeinek aktuális száma. 


tárolóadapter (container adapter) Az STL-ben olyan csomagolóosztályok, amelyek 
egy belső tároló interfészéhez csak korlátozott hozzáférést engednek valamely új 
tárolótípus megvalósítása végett. 


tartomány (range) Az STL-ben az iterátorok egy balról zárt, jobbról nyílt intervalluma. 


teljes bináris fa (complete binary tree) Olyan bináris fa, amelyben minden csomó- 
pontnak két gyermeke van, kivéve a legalsó szinten, ahol balról jobbra csak egy bi- 
zonyos pontig vannak levelek, tovább viszont nem. 


típusbiztos (type safe) Olyan konverzióra, függvényre vagy akár osztályra használa- 
tos kifejezés, amelynél biztosak lehetünk, hogy futás közben nem kapunk konver- 
ziós hibát. 


típustámogatás A Ct--ban a felhasználó által definiált típusok —közöttük az osztá- 
lyok — úgy viselkedhetnek, mint a beépített típusok. 


tisztán virtuális függvény (pure virtual function) Olyan virtuális tagfüggvény, amely- 
nek nem definiáljuk a törzsét. 
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Kislexikon 
több-bájtos karakterkódolás (multibyte encodi 
egyes karakterek értéküktől függően ÖVE el e yeléspi karakterkódolás, ahol az 


Í7ő elapátk És bájton tárolódnak. 
többnyei ps sic Multilingual Pl. 4 
FFFF-ig terjedő kódponttartomány—— a ivode szabványban a 0000-tól 


UML osztálydiagram (UML class di. 
taikat megjelenítő diagram, 


Unicode transzformációs formátum (Unicode Transft i 
5; ormation Foi it 
szabványban a kódpontok bájtsorozatra történő lekésezésédöl TO vapedesélk aj 


Véletlen hozzáférésű iterátor (random access itei i 
amelyekre értelmezettek a pointerekre rvényős SZ özeésgiss AR na 


virtuális alaposztály (virtual base class) A 044 
c 1 nyelvben a leszármaztatá. 
ősosztály virtuális alaposztályként is megadható. A virtuális Ákpészály tiztálee 
zói csak egyszer szerepelnek a leszármazottban, ha az osztály minden öröklési 
ágon virtuális alaposztályként lett megadva. si; 


agram) Az UML-ben az osztályokat és kapcsola. 
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